Thread (67 messages) 67 messages, 10 authors, 2021-08-25

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

From: Paul Moore <paul@paul-moore.com>
Date: 2021-06-02 17:21:23
Also in: linux-fsdevel, linux-security-module, selinux

On Wed, Jun 2, 2021 at 11:38 AM Richard Guy Briggs [off-list ref] wrote:
On 2021-06-01 21:40, Paul Moore wrote:
quoted
On Mon, May 31, 2021 at 9:44 AM Richard Guy Briggs [off-list ref] wrote:
quoted
On 2021-05-30 11:26, Paul Moore wrote:
quoted
On Fri, May 28, 2021 at 6:36 PM Richard Guy Briggs [off-list ref] wrote:
quoted
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.
The only io_uring syscalls are io_uring_setup(2), io_uring_enter(2),
etc., the stuff that is dispatched in io_issue_sqe() are the io_uring
ops/opcodes/whatever.  They *look* like syscalls but they are not and
we have to treat them differently.
quoted
It isn't an issue of "can" the filters be separate, they *have* to be separate.
-- 
paul moore
www.paul-moore.com
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help