[RFC PATCH v2 0/9] Add LSM access controls and auditing to io_uring

[Paul Moore]

On Mon, Sep 13, 2021 at 9:50 PM Paul Moore <paul at paul-moore.com> wrote:
> On Mon, Sep 13, 2021 at 3:23 PM Paul Moore <paul at paul-moore.com> wrote:
> > On Thu, Sep 9, 2021 at 8:59 PM Richard Guy Briggs <rgb at redhat.com> wrote:
> > > On 2021-09-01 15:21, Paul Moore wrote:
> > > > On Sun, Aug 29, 2021 at 11:18 AM Paul Moore <paul at paul-moore.com> wrote:
> > > > > On Sat, Aug 28, 2021 at 11:04 AM Richard Guy Briggs <rgb at redhat.com> wrote:
> > > > > > I did set a syscall filter for
> > > > > >         -a exit,always -F arch=b64 -S io_uring_enter,io_uring_setup,io_uring_register -F key=iouringsyscall
> > > > > > and that yielded some records with a couple of orphans that surprised me
> > > > > > a bit.
> > > > >
> > > > > Without looking too closely at the log you sent, you can expect URING
> > > > > records without an associated SYSCALL record when the uring op is
> > > > > being processed in the io-wq or sqpoll context.  In the io-wq case the
> > > > > processing is happening after the thread finished the syscall but
> > > > > before the execution context returns to userspace and in the case of
> > > > > sqpoll the processing is handled by a separate kernel thread with no
> > > > > association to a process thread.
> > > >
> > > > I spent some time this morning/afternoon playing with the io_uring
> > > > audit filtering capability and with your audit userspace
> > > > ghau-iouring-filtering.v1.0 branch it appears to work correctly.  Yes,
> > > > the userspace tooling isn't quite 100% yet (e.g. `auditctl -l` doesn't
> > > > map the io_uring ops correctly), but I know you mentioned you have a
> > > > number of fixes/improvements still as a work-in-progress there so I'm
> > > > not too concerned.  The important part is that the kernel pieces look
> > > > to be working correctly.
> > >
> > > Ok, I have squashed and pushed the audit userspace support for iouring:
> > >         https://github.com/rgbriggs/audit-userspace/commit/e8bd8d2ea8adcaa758024cb9b8fa93895ae35eea
> > >         https://github.com/linux-audit/audit-userspace/compare/master...rgbriggs:ghak-iouring-filtering.v2.1
> > > There are test rpms for f35 here:
> > >         http://people.redhat.com/~rbriggs/ghak-iouring/git-e8bd8d2-fc35/
> > >
> > > userspace v2 changelog:
> > > - check for watch before adding perm
> > > - update manpage to include filesystem filter
> > > - update support for the uring filter list: doc, -U op, op names
> > > - add support for the AUDIT_URINGOP record type
> > > - add uringop support to ausearch
> > > - add uringop support to aureport
> > > - lots of bug fixes
> > >
> > > "auditctl -a uring,always -S ..." will now throw an error and require
> > > "-U" instead.
> >
> > Thanks Richard.
> >
> > FYI, I rebased the io_uring/LSM/audit patchset on top of v5.15-rc1
> > today and tested both with your v1.0 and with your v2.1 branch and the
> > various combinations seemed to work just fine (of course the v2.1
> > userspace branch was more polished, less warts, etc.).  I'm going to
> > go over the patch set one more time to make sure everything is still
> > looking good, write up an updated cover letter, and post a v3 revision
> > later tonight with the hope of merging it into -next later this week.
>
> Best laid plans of mice and men ...
>
> It turns out the LSM hook macros are full of warnings-now-errors that
> should likely be resolved before sending anything LSM related to
> Linus.  I'll post v3 once I fix this, which may not be until tomorrow.
>
> (To be clear, the warnings/errors aren't new to this patchset, I'm
> likely just the first person to notice them.)

Actually, scratch that ... I'm thinking that might just be an oddity
of the Intel 0day test robot building for the xtensa arch.  I'll post
the v3 patchset tonight.

-- 
paul moore
www.paul-moore.com