linux-kernel - Re: f_modown and LSM inconsistency (was [PATCH v2 1/4] Landlock: Add signal control)

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: <CAHC9VhRh3gBLv=qmbz35UHing_qz7xJe1T98UJSN=bd5zeAwVg@mail.gmail.com>
Date: Mon, 12 Aug 2024 14:17:24 -0400
From: Paul Moore <paul@...l-moore.com>
To: Mickaël Salaün <mic@...ikod.net>
Cc: Jann Horn <jannh@...gle.com>, Christian Brauner <brauner@...nel.org>, 
	Al Viro <viro@...iv.linux.org.uk>, Casey Schaufler <casey@...aufler-ca.com>, 
	Tahera Fahimi <fahimitahera@...il.com>, gnoack@...gle.com, jmorris@...ei.org, 
	serge@...lyn.com, linux-security-module@...r.kernel.org, 
	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org
Subject: Re: f_modown and LSM inconsistency (was [PATCH v2 1/4] Landlock: Add
 signal control)

On Mon, Aug 12, 2024 at 1:28 PM Mickaël Salaün <mic@...ikod.net> wrote:
> On Mon, Aug 12, 2024 at 12:30:03PM -0400, Paul Moore wrote:
> > On Mon, Aug 12, 2024 at 11:06 AM Jann Horn <jannh@...gle.com> wrote:
> > > On Mon, Aug 12, 2024 at 4:57 PM Paul Moore <paul@...l-moore.com> wrote:
> > > > On Mon, Aug 12, 2024 at 9:09 AM Jann Horn <jannh@...gle.com> wrote:
> > > > > On Mon, Aug 12, 2024 at 12:04 AM Paul Moore <paul@...l-moore.com> wrote:
> > > >
> > > > ...
> > > >
> > > > > > From a LSM perspective I suspect we are always going to need some sort
> > > > > > of hook in the F_SETOWN code path as the LSM needs to potentially
> > > > > > capture state/attributes/something-LSM-specific at that
> > > > > > context/point-in-time.
> > > > >
> > > > > The only thing LSMs currently do there is capture state from
> > > > > current->cred. So if the VFS takes care of capturing current->cred
> > > > > there, we should be able to rip out all the file_set_fowner stuff.
> > > > > Something like this (totally untested):
> > > >
> > > > I've very hesitant to drop the LSM hook from the F_SETOWN path both
> > > > because it is reasonable that other LSMs may want to do other things
> > > > here,
> > >
> > > What is an example for other things an LSM might want to do there? As
> > > far as I understand, the whole point of this hook is to record the
> > > identity of the sender of signals - are you talking about an LSM that
> > > might not be storing credentials in struct cred, or something like
> > > that?
> >
> > Sure.  The LSM framework is intentionally very vague and limited on
> > what restrictions it places on individual LSMs; we want to be able to
> > support a wide range of security models and concepts.  I view the
> > F_SETOWN hook are important because it is a control point that is used
> > to set/copy/transfer/whatever security attributes from the current
> > process to a file/fd for the purpose of managing signals on the fd.
> >
> > > > and adding a LSM hook to the kernel, even if it is re-adding a
> > > > hook that was previously removed, is a difficult and painful process
> > > > with an uncertain outcome.
> > >
> > > Do you mean that even if the LSM hook ends up with zero users
> > > remaining, you'd still want to keep it around in case it's needed
> > > again later?
> >
> > I want the security_file_set_fowner() hook to remain a viable hook for
> > capturing the current task's security attributes, regardless of what
> > security attributes the LSM is interested in capturing and where those
> > attributes are stored.
>
> I don't see the point to keep an unused hook, we could add it back later
> if there is a valid use case, but I'll send a v2 without this removal.

If it was simple to add LSM hooks, then I would agree, but history has
shown that not to be the case.

-- 
paul-moore.com