On Mon, May 18, 2026 at 8:01 PM Song Liu <[email protected]> wrote: > On Mon, May 18, 2026 at 4:57 PM Paul Moore <[email protected]> wrote: > > On Mon, May 18, 2026 at 7:23 PM Song Liu <[email protected]> wrote: > > > On Mon, May 18, 2026 at 2:29 PM Paul Moore <[email protected]> wrote: > > > [...] > > > > 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. > > > > > > > > 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. > > > > > > > > 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. > > > > > > I don't think we can use NOKPROBE_SYMBOL(). There are functions > > > that we don't want to killswitch, but still want to trace. > > > > That was exactly my point, but we need to figure something out so > > killswitch doesn't make it easier to cause a regression. > > killswitch is making it easier to fix a CVE. It can surely make it easier > to cause a regression. AFAICT, the only protection here is "it is only > for root".
As I mentioned earlier, several LSMs have the ability to restrict root beyond what is possible with traditional Linux accesscontrols. For example, with SELinux one could deny root a specific privilege while also blocking changes to the SELinux policy; the root user would not be able to restore that privilege without rebooting the system. On a killswitch enabled system the ability to restrict root is lost as root would be able to kill the enforcement of those access controls. Presumably one could have the LSM block access to killswitch in this particular case, but that defeats the purpose doesn't it? The audit subsystem also has a somewhat similar one-way configuration lock, which when set does not allow even root to unlock it, a reboot is required. By a bit of luck with regards to how the code is written*, it may not be vulnerable to a killswitch regression but I do wonder if there are other similar things in the kernel which would have the same type of problem. * This is probably the first time I think I've ever considered myself lucky with respect to the audit code implementation. -- paul-moore.com
