Re: [RFC PATCH 2/9] audit,io_uring,io-wq: add some basic audit support to io_uring
On 2021-05-26 11:22, Jens Axboe wrote:
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?
These may be poor examples, but hear me out...
In the case of an open call, I'm guessing that they are mapped 1:1
syscall to io_uring action so that the action can be asynchronous. So
in this case, there is a record of the action, but we don't see the
result success/failure. I assume that file paths can only be specified
in the original syscall and not in an SQPOLL action?
In the case of a syscall read/write (which aren't as interesting
generally to audit, but I'm concerned there are other similar situations
that are), the syscall would be called for every buffer that is passed
back and forth user/kernel and vice versa, providing a way to log all
that activity. In the case of SQPOLL, I understand that a syscall sets
up the action and then io_uring takes over and does the bulk transfer
and we'd not have the visibility of how many times that action was
repeated nor that the result success/failure was due to its asynchrony.
Perhaps I am showing my ignorance, so please correct me if I have it
wrong.
>> 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!
Paul addressed this in his reply, but let me add a more concrete
example... There was one corner case I was looking at that showed up
this issue. Please indicate if I have mischaracterized or
misunderstood.
A syscall would generate records something like this:
AUDIT_SYSCALL
AUDIT_...
AUDIT_EOE
A io_uring SQPOLL event would generate something like this:
AUDIT_URINGOP
AUDIT_...
AUDIT_EOE
The "hybrid" event that is a syscall that starts an io_uring action
would generate something like this:
AUDIT_URINGOP
[possible AUDIT_CONFIG_CHANGE (from killed_trees)]
AUDIT_SYSCALL
AUDIT_...
AUDIT_EOE
The AUDIT_... is all the operation-specific records that log parameters
that aren't able to be expressed in the SYSLOG or URINGOP records such
as pathnames, other arguments, and context (pwd, etc...). So this isn't
"double logging". It is either introducing an io_uring event, or it is
providing more detail about the io_uring arguments to a syscall event.
Jens Axboe
- RGB
--
Richard Guy Briggs <rgb(a)redhat.com>
Sr. S/W Engineer, Kernel Security, Base Operating Systems
Remote, Ottawa, Red Hat Canada
IRC: rgb, SunRaycer
Voice: +1.647.777.2635, Internal: (81) 32635