Re: [RFC PATCH 2/9] audit,io_uring,io-wq: add some basic audit support to io_uring
On 5/26/21 9:49 AM, Richard Guy Briggs wrote:
> So why is there anything special needed for io_uring (now that
the
> native worker threads are used)?
Because syscall has been bypassed by a memory-mapped work queue.
I don't follow this one at all, that's just the delivery mechanism if
you choose to use SQPOLL. If you do, then a thread sibling of the
original task does the actual system call. There's no magic involved
there, and the tasks are related.
So care to expand on that?
> Is there really any io_uring opcode that bypasses the security
checks the corresponding native syscall
> would do? If so, I think that should just be fixed...
This is by design to speed it up. This is what Paul's iouring entry and
exit hooks do.
As far as I can tell, we're doing double logging at that point, if the
syscall helper does the audit as well. We'll get something logging the
io_uring opcode (eg IORING_OP_OPENAT2), then log again when we call the
fs helper. That's _assuming_ that we always hit the logging part when we
call into the vfs, but that's something that can be updated to be true
and kept an eye on for future additions.
Why is the double logging useful? It only tells you that the invocation
was via io_uring as the delivery mechanism rather than the usual system
call, but the effect is the same - the file is opened, for example.
I feel like I'm missing something here, or the other side is. Or both!
--
Jens Axboe