On Tue, May 19, 2026 at 1:29 AM Song Liu <[email protected]> wrote: > 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.
I don't know if I would say it is necessarily more granular as its ability to filter access is limited to a breakpoint set on a symbol, but killswitch definitely has a larger quantity of control points. > 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. Yes, I think we agree here. > 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. ... and Android has been shown to not be vulnerable in the first place due to their use of SELinux and a well crafted SELinux policy. -- paul-moore.com
