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

[Paul Moore]

On Mon, Aug 12, 2024 at 11:06 AM Jann Horn <jannh at google.com> wrote:
> On Mon, Aug 12, 2024 at 4:57 PM Paul Moore <paul at paul-moore.com> wrote:
> > On Mon, Aug 12, 2024 at 9:09 AM Jann Horn <jannh at google.com> wrote:
> > > On Mon, Aug 12, 2024 at 12:04 AM Paul Moore <paul at paul-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.

-- 
paul-moore.com