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. > >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. > >The use of kprobes, while an interesting idea, presents problems as > >allowing any kernel symbol to be killed introduces the potential for > >security regressions. As a reminder, some LSMs, as well as other > >kernel subsystems, have mechanisms in place to restrict root and/or > >enforce one-way configuration locks; while many people equate "root" > >with full control, in many cases today that is not strictly correct. > > killswitch "complies" with lockdown. Is there a different scenario which we > should be blocking? See the SELinux example I mentioned in my email to Song. > >Yes, kprobes have been around for some time, this is not a new > >problem, but killswitch makes it far more convenient and accessible to > >do dangerous things with kprobes. If killswitch makes it past the RFC > >stage without any significant changes to its kill mechanism, we may > >need to start considering more liberal usage of NOKPROBE_SYMBOL() > >which I think would be an unfortunate casualty. > > Why? If I don't really mind the security impact, I want to be able to have a > killswitch-like interface on my systems. If an attacker is in my systems, > killswitch is the least of my concerns I think. > > If you are security concious, just don't enable CONFIG_KILLSWITCH? Isn't the whole point of killswitch to have it enabled everywhere because you never know when you might want/need it? -- paul-moore.com
