On Mon, Aug 12, 2024 at 1:28 PM Mickaël Salaün [off-list ref] wrote:

On Mon, Aug 12, 2024 at 12:30:03PM -0400, Paul Moore wrote:

quoted

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

quoted

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

quoted

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?

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.

quoted

quoted

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