On Tue, May 7, 2024 at 10:35 PM Kees Cook <keescook@xxxxxxxxxxxx> 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
