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

On Mon, Aug 12, 2024 at 4:57 PM Paul Moore [off-list ref] wrote:

On Mon, Aug 12, 2024 at 9:09 AM Jann Horn [off-list ref] wrote:

quoted

On Mon, Aug 12, 2024 at 12:04 AM Paul Moore [off-list ref] wrote:

...

quoted

quoted

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?