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

[Jann Horn]

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?

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