Date: Sun, 8 Dec 2019 12:58:34 +0100 From: Solar Designer <solar@...nwall.com> To: lkrg-users@...ts.openwall.com Subject: Re: bug: LKRG kills VirtualBox host VMs On Sun, Dec 08, 2019 at 06:36:40AM +0000, Patrick Schleizer wrote: > Solar Designer: > > As to your concerns on having an extra security-sensitive flag, we > > already have some other sysctl's that also affect LKRG in > > security-relevant ways. I think we need to come up with a common > > approach and framework for protecting all of those flags from easy > > one-shot overwrites or/and making such overwrites ineffective (read-only > > pages or/and checking against a keyed hash or redundant copies), and > > use it for all of LKRG's security-sensitive rarely-changing variables. > > > > Right now, LKRG's approach to these issues is inconsistent: some > > settings are security-sensitive yet runtime configurable, and some > > others are compile-time only. We need to make LKRG consistent. > > Maybe a single call "sudo sysctl -w lkrg.fuse=1" could make all LKRG > settings ready-only until reboot? Before that, all settings are read/write? > > I am also looking for a sysctl command to fuse all (not only LKRG) > sysctl settings, but I don't know if that would be overreaching LKRG's > scope. (Similar to linux "lockdown" feature.) Both of these suggestions seem reasonable on the surface, but I think are unreasonable once you dig deeper. Protecting the kernel from legitimate(*) root for real requires not only a lock-down of the kernel, but also of the userland, and a system like this becomes difficult to use and requires greater skill to use reasonably. Adam planned some lock-down features in the "experimental" branch of LKRG, but I oppose that direction because I expect only a negligible percentage of users will make reasonable use of those. (*) "Legitimate" as in "indistinguishable from legitimate by LKRG". What LKRG can reasonably do is protect its settings from attacks that are still in progress and haven't yet reached the point of having legitimate-looking root access. I suggested some ways to achieve that above. In that context, your suggestion for permanently locking down the settings makes sense for code simplification if it'd be the only mode we'd implement. It would also very slightly improve security through LKRG lacking gadgets (code snippets potentially reusable by an exploit's execution chain) that would unlock the settings, and which we'd have in there if one of my suggested approaches is implemented. However, we already have in LKRG some potential gadgets updating its existing databases. Randomization of kernel module load addresses (by the Linux kernel that LKRG is loaded into) should help prevent easy use of LKRG gadgets by exploits. We could also validate stack frames from within such gadgets. Alexander
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.