linux-kernel - Re: [PATCH v3 2/2] lsm,io_uring: add LSM hooks for io_uring

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHC9VhTAunsgA-k64-qmQzeyvmAHuQ-=Jp-yWDi9XDP9CHkhHA@mail.gmail.com>
Date: Tue, 28 Jan 2025 17:35:26 -0500
From: Paul Moore <paul@...l-moore.com>
To: Casey Schaufler <casey@...aufler-ca.com>
Cc: Hamza Mahfooz <hamzamahfooz@...ux.microsoft.com>, linux-kernel@...r.kernel.org, 
	James Morris <jmorris@...ei.org>, "Serge E. Hallyn" <serge@...lyn.com>, Jens Axboe <axboe@...nel.dk>, 
	Pavel Begunkov <asml.silence@...il.com>, Stephen Smalley <stephen.smalley.work@...il.com>, 
	Ondrej Mosnacek <omosnace@...hat.com>, Bram Bonné <brambonne@...gle.com>, 
	Thiébaud Weksteen <tweek@...gle.com>, 
	Christian Göttsche <cgzones@...glemail.com>, 
	Masahiro Yamada <masahiroy@...nel.org>, linux-security-module@...r.kernel.org, 
	io-uring@...r.kernel.org, selinux@...r.kernel.org
Subject: Re: [PATCH v3 2/2] lsm,io_uring: add LSM hooks for io_uring_setup()

On Mon, Jan 27, 2025 at 7:23 PM Casey Schaufler <casey@...aufler-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@...aufler-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.

> > 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.

-- 
paul-moore.com