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

From: Paul Moore <paul@paul-moore.com>
To: Richard Guy Briggs <rgb@redhat.com>
Cc: Jens Axboe <axboe@kernel.dk>,
	selinux@vger.kernel.org, Pavel Begunkov <asml.silence@gmail.com>,
	linux-security-module@vger.kernel.org, linux-audit@redhat.com,
	Kumar Kartikeya Dwivedi <memxor@gmail.com>,
	linux-fsdevel@vger.kernel.org, io-uring@vger.kernel.org
Subject: Re: [RFC PATCH v2 0/9] Add LSM access controls and auditing to io_uring
Date: Mon, 13 Sep 2021 15:23:41 -0400	[thread overview]
Message-ID: <CAHC9VhSRJYW7oRq6iLCH_UYukeFfE0pEJ_wBLdr1mw2QGUPh-Q@mail.gmail.com> (raw)
In-Reply-To: <20210910005858.GL490529@madcap2.tricolour.ca>

On Thu, Sep 9, 2021 at 8:59 PM Richard Guy Briggs <rgb@redhat.com> wrote:
> On 2021-09-01 15:21, Paul Moore wrote:
> > On Sun, Aug 29, 2021 at 11:18 AM Paul Moore <paul@paul-moore.com> wrote:
> > > On Sat, Aug 28, 2021 at 11:04 AM Richard Guy Briggs <rgb@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.

-- 
paul moore
www.paul-moore.com

--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit