Re: [PATCH v3 2/2] lsm,io_uring: add LSM hooks for io_uring_setup()

Casey Schaufler
2025-01-28T00:43:50Z

On 1/27/2025 1:23 PM, Paul Moore wrote:
> On Mon, Jan 27, 2025 at 12:18 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>> On 1/27/2025 7:57 AM, Hamza Mahfooz wrote:
>>> It is desirable to allow LSM to configure accessibility to io_uring
>>> because it is a coarse yet very simple way to restrict access to it. So,
>>> add an LSM for io_uring_allowed() to guard access to io_uring.
>> I don't like this at all at all. It looks like you're putting in a hook
>> so that io_uring can easily deflect any responsibility for safely
>> interacting with LSMs.
> That's not how this works Casey, unless you're seeing something different?

Yes, it's just me being paranoid. When a mechanism is introduced that makes
it easy to disable a system feature in the LSM environment I start hearing
voices saying "You can't use security and the cool thing together", and the
developers of "the cool thing" wave hands and say "just disable it" and it
never gets properly integrated. I have seen this so many times it makes me
wonder how anything ever does get made to work in multiple configurations.

>
> This is an additional access control point for io_uring, largely to
> simplify what a LSM would need to do to help control a process' access
> to io_uring, it does not replace any of the io_uring LSM hooks or
> access control points.

What I see is "LSM xyzzy has an issue with io_uring? Just create a
io_uring_allowed() hook that always disables io_uring." LSM xyzzy never
gets attention from the io_uring developers because, as far as they care,
the problem is solved.