[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <632555ee-4e44-fba4-476c-9fab2d215a3c@riseup.net>
Date: Mon, 9 Dec 2019 09:06:17 +0000
From: Patrick Schleizer <adrelanos@...eup.net>
To: lkrg-users@...ts.openwall.com
Subject: Re: bug: LKRG kills VirtualBox host VMs
Solar Designer:
> 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.
Agreed, this is not easy to do. And I haven't seen Linux desktop
distributions implementing that. At Whonix / Kicksecure we're working
towards that, on a full system mandatory access control (MAC) profile
using AppArmor, and untrusted root. [1] [2] [3]
(This is not a feature to restrict legitimate sysaminds / user freedom.
Users will be able to opt-out / remove this feature even using a grub
boot menu option likely.)
> 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.
Understandably. I guess if your apparmor-profile-everything prohibits
root from running sysctl and writing into /etc/sysctl.d (only the
package manager will be able to do that), among other things, that is as
good as sysctl lockdown.
Kind regards,
Patrick
[1] https://github.com/Whonix/apparmor-profile-everything
[2]
https://forums.whonix.org/t/apparmor-for-complete-system-including-init-pid1-systemd-everything-full-system-mac-policy/8339
[3]
https://forums.whonix.org/t/untrusted-root-improve-security-by-restricting-root/7998
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.
