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.
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?
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?
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? -- Thanks, Sasha
