[PATCH bpf-next v10 5/5] bpf: Only enable BPF LSM hooks when an LSM program is attached

[Paul Moore]

On Tue, May 7, 2024 at 10:35 PM Kees Cook <keescook at chromium.org> wrote:
>
> On Tue, May 07, 2024 at 09:45:09PM -0400, Paul Moore wrote:
> > I don't want individual LSMs manipulating the LSM hook state directly;
> > they go through the LSM layer to register their hooks, they should go
> > through the LSM layer to unregister or enable/disable their hooks.
> > I'm going to be pretty inflexible on this point.
>
> No other LSMs unregister or disable hooks. :)

To be clear, it doesn't really matter if it is all of the LSMs or just
one; preserving the interface abstraction as much as possible is
worthwhile and good.

> > Honestly, I see this more as a problem in the BPF LSM design (although
> > one might argue it's an implementation issue?), just as I saw the
> > SELinux runtime disable as a problem.  If you're upset with the
> > runtime hook disable, and you should be, fix the BPF LSM, don't force
> > more bad architecture on the LSM layer.
>
> We'll have to come back to this later. It's a separate (but closely
> related) issue.

It's a moot point given KP's latest suggestion, but just to give some
insight on priorities, correctness is always my primary concern and
while the performance improvement in this patchset is a nice win, the
most interesting part to me was that it provided a solution for the
empty-BPF-LSM-hook problem that has been an ongoing source of
problems.  Yes, we have made a number of improvements in that area,
and I expect those to continue, but selectively enabling/disabling the
BPF LSM hook implementations is a big step forward.

-- 
paul-moore.com