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?
>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.
>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?
Right. We have different usecases. If you want selinux/lockdown/etc and a
really crippled root, that should be an option. If you choose to allow
something like killswitch, it should be an option too.
--
Thanks,
Sasha
