On Mon, Aug 12, 2024 at 1:28 PM Mickaël Salaün <mic@xxxxxxxxxxx> 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@xxxxxxxxxx> wrote: > > > On Mon, Aug 12, 2024 at 4:57 PM Paul Moore <paul@xxxxxxxxxxxxxx> wrote: > > > > On Mon, Aug 12, 2024 at 9:09 AM Jann Horn <jannh@xxxxxxxxxx> wrote: > > > > > On Mon, Aug 12, 2024 at 12:04 AM Paul Moore <paul@xxxxxxxxxxxxxx> 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
