Re: [RFC PATCH 4/9] audit: add filtering for io_uring records

On 2021-06-01 21:40, Paul Moore wrote: > On Mon, May 31, 2021 at 9:44 AM Richard Guy Briggs <rgb(a)redhat.com&gt; wrote: > > On 2021-05-30 11:26, Paul Moore wrote: > > > On Fri, May 28, 2021 at 6:36 PM Richard Guy Briggs <rgb(a)redhat.com&gt; wrote: > > > > On 2021-05-21 17:50, Paul Moore wrote: > > > > If we abuse the syscall infrastructure at first, we'd need a transition > > > > plan to coordinate user and kernel switchover to seperate mechanisms for > > > > the two to work together if the need should arise to have both syscall > > > > and uring filters in the same rule. > > > > > > See my comments above, I don't currently see why we would ever want > > > syscall and io_uring filtering to happen in the same rule. Please > > > speak up if you can think of a reason why this would either be needed, > > > or desirable for some reason. > > > > I think they can be seperate rules for now. Either a syscall rule > > catching all io_uring ops can be added, or an io_uring rule can be added > > to catch specific ops. The scenario I was thinking of was catching > > syscalls of specific io_uring ops. > > Perhaps I'm misunderstand you, but that scenario really shouldn't > exist. The io_uring ops function independently of syscalls; you can > *submit* io_uring ops via io_uring_enter(), but they are not > guaranteed to be dispatched synchronously (obviously), and given the > cred shenanigans that can happen with io_uring there is no guarantee > the filters would even be applicable. That wasn't my understanding. There are a number of io_uring calls starting with at least open that are currently synchronous (but may become async in future) that we may want to single out which would be a specific io_uring syscall with a specific io_uring opcode. I guess that particular situation would be caught by the io_uring opcode triggering an event that includes SYSCALL and URINGOP records.

> It isn't an issue of "can" the filters be separate, they *have* to be separate.