On Tue, May 19, 2026 at 4:00 PM Sasha Levin <[email protected]> wrote: > On Mon, May 18, 2026 at 11:08:38PM -0400, Paul Moore wrote: > >On Mon, May 18, 2026 at 8:31 PM Sasha Levin <[email protected]> wrote: > >> On Mon, May 18, 2026 at 05:29:32PM -0400, Paul Moore wrote: > >> >From my perspective there are two different issues here: should > >> >killswitch be a LSM, and should killswitch leverage kprobes to be able > >> >to "kill" security related symbols. After all, are we okay with > >> >killswitch killing capable() and friends? > >> > >> killswitch doesn't do it on it's own. It may be instructed by root to do > >> that, > >> at which point that is root's problem. > > > >As I mentioned previously, there are cases where we can restrict > >root's privileges today, but a functional killswitch would allow that > >restriction to be bypassed. My last email to Song has an example with > >SELinux. > > This would be handled by just disabling killswitch in those scenarios like how > we do with lockdown, no?
One could presumably deny access to killswitch, but that pushes the burden of choice onto the users/admins. Yes, that is the easy way to solve thorny use case conflicts like this, but it would be nice if we could do better for those who have to deal with this in the wild. > >> >In my opinion, making killswitch an LSM is more of a procedural item > >> >that deals with how we view a capability like killswitch. I > >> >personally view killswitch as somewhat similar to Lockdown, which is > >> >why I made the suggestion. > >> > >> Maybe I'm not all that familiar with LSMs, but we would need to be able to > >> stop > >> "random" code paths from executing, and I don't think we can create LSM > >> hooks > >> at that granularity, no? > > > >I don't see any LSM hooks in this revision of killswitch, and as long > >as it is based on a kprobes I can't imagine it would ever use any. As > >I mentioned above, my killswitch-as-a-LSM comment is primarily about > >killswitch filling a role very similar to Lockdown. > > My question was more about how to structure killswitch as an LSM. I want to be > able to poke at pretty much any function in the kernel, rather than restrict > access to a known list of functions. Well, like I said in my last reply to you, I can't imagine a kprobes based killswitch would need to worry about the LSM hooks. Structuring killswitch as an LSM would be mostly a few lines of code to register it as an LSM and that's about it. Benefits would be minor, and likely a matter of opinion, it's mostly about how we view something like killswitch in the kernel. If we view it as a security mechanism similar to lockdown, then it makes sense as a LSM, if we view this as a completely different thing then it can be whatever it wants to be. -- paul-moore.com
