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

[Casey Schaufler <casey@schaufler-ca.com>]

On 1/28/2025 2:35 PM, Paul Moore wrote:
> On Mon, Jan 27, 2025 at 7:23 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>> 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.
> While there is plenty of precedent regarding paranoia over kernel
> changes outside the LSM, and yes, I do agree that there are likely
> some configurations that aren't tested (or make little sense for that
> matter), I don't believe that to be the case here.  The proposed LSM
> hook is simply another access control, and it makes it much easier for
> LSMs without full and clear anonymous inode controls to apply access
> controls to io_uring.

I can't say I agree that it's an access control because although it is
specific to a process it isn't specific to an object. You can still access
the set of objects using other means. It is a mechanism control, preventing
use of io_uring entirely.

>>> 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.
> To be honest, I wouldn't expect the io_uring developers (or any kernel
> subsystem maintainer outside the LSMs) to worry about a specific LSM.
> The io_uring developers should be focused on ensuring that the LSM
> hooks for io_uring are updated as necessary and called from all of the
> right locations as io_uring continues to evolve.  If there is a
> problem with LSM xyzzy because it provides a buggy LSM callback for
> the io_uring LSM hooks, that is a xyzzy issue not an io_uring issue.

I'm much more concerned about bugs in io_uring than in xyzzy. The io_uring
people have been pretty good about addressing LSM issues, so it's not
a huge deal, but I never like seeing switches to turn off features because
security is active.

If no one else shares my concern you can put my comments down to the
ravings of the lunatic fringe and ignore them.