On Mon, May 18, 2026 at 5: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. > > >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?
There are much fewer LSM hooks than ftrace-able (killswitch-able) functions. In this sense, killswitch is more granular. However, LSM hooks allow LSM policies to make different decisions for different arguments. In this sense, LSM hooks are more granular than killswitch, as killswitch can only set a fixed return value for each engaged function. With current LSM solutions, we can mitigate issues like Copy Fail without breaking other features of the system. In [1], Cloudflare shared how they mitigate Copy Fail with BPF LSM. Thanks, Song [1] https://blog.cloudflare.com/copy-fail-linux-vulnerability-mitigation/
