Re: [RFC PATCH 2/9] audit,io_uring,io-wq: add some basic audit support to io_uring

On Tue, May 25, 2021 at 9:11 PM Jens Axboe <axboe(a)kernel.dk&gt; wrote: > On 5/24/21 1:59 PM, Paul Moore wrote: >> That said, audit is not for everyone, and we have build time and >> runtime options to help make life easier. Beyond simply disabling >> audit at compile time a number of Linux distributions effectively >> shortcut audit at runtime by adding a "never" rule to the audit >> filter, for example: >> >> % auditctl -a task,never > > As has been brought up, the issue we're facing is that distros have > CONFIG_AUDIT=y and hence the above is the best real world case outside > of people doing custom kernels. My question would then be how much > overhead the above will add, considering it's an entry/exit call per op. > If auditctl is turned off, what is the expectation in turns of overhead? I commented on that case in my last email to Pavel, but I'll try to go over it again in a little more detail. As we discussed earlier in this thread, we can skip the req->opcode check before both the _entry and _exit calls, so we are left with just the bare audit calls in the io_uring code. As the _entry and _exit functions are small, I've copied them and their supporting functions below and I'll try to explain what would happen in CONFIG_AUDIT=y, "task,never" case. + static inline struct audit_context *audit_context(void) + { + return current->audit_context; + } + static inline bool audit_dummy_context(void) + { + void *p = audit_context(); + return !p || *(int *)p; + } + static inline void audit_uring_entry(u8 op) + { + if (unlikely(audit_enabled && audit_context())) + __audit_uring_entry(op); + }

We would need to check with the current security requirements (there are distro people on the linux-audit list that keep track of that stuff), but looking at the opcodes right now my gut feeling is that most of the opcodes would be considered "security relevant" so selective auditing might not be that useful in practice. It would definitely clutter the code and increase the chances that new opcodes would not be properly audited when they are merged.