[RFC PATCH] lsm: fixup the inode xattr capability handling

Paul Moore paul at paul-moore.com
Sat Jul 6 04:31:59 UTC 2024


On Fri, Jul 5, 2024 at 4:28 PM KP Singh <kpsingh at chromium.org> wrote:
> > On 3 May 2024, at 02:58, Paul Moore <paul at paul-moore.com> wrote:

...

> > Before we discuss the solution, there are a few observations and
> > considerations that we need to take into account:
> > * BPF LSM registers an implementation for every LSM hook, and that
> >  implementation simply returns the hook's default return value, a
> >  0 in this case.  We want to ensure that the default BPF LSM behavior
> >  results in the capability checks being called.

...

> If you want to go ahead with this change for other reasons, please feel free to. But, I don't want the BPF LSM default callbacks being cited as a reason here.

As mentioned previously in this thread, over a month ago, the patch is
in the lsm/dev branch and is therefore scheduled to go up to Linus
during the next merge window.  It may be worth noting that the current
BPF LSM behavior is cited not as a "reason" but merely as part of the
"observations and considerations" along with the SELinux and Smack
behaviors.  If you look at the full description as well as the patch
itself, you'll notice that the core issue really is more about legacy
SELinux and Smack behaviors, not that of the BPF LSM.  The
considerations section that you highlighted is simply there to provide
some background on how things work to help the reader better
understand the approach taken in the patch.

-- 
paul-moore.com



More information about the Linux-security-module-archive mailing list