lkrg-users - Re: bug: LKRG kills VirtualBox host VMs

Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200124051751.GA6929@pi3.com.pl>
Date: Fri, 24 Jan 2020 06:17:51 +0100
From: Adam Zabrocki <pi3@....com.pl>
To: lkrg-users@...ts.openwall.com
Subject: Re: bug: LKRG kills VirtualBox host VMs

Hi,

LKRG has now a RO page where we keep sysctl configuration, and we have decided 
to introduce 2 new interfaces which are replacing P_LKRG_CI_X86_NO_MSR and 
P_LKRG_PCFI_NO_STACKWALK compilation macros:

    1) enforce_msr enabled by default:
         lkrg.enforce_msr:
            0 - disable MSRs verification during CI
            1 - enable MSRs verification during CI

    2) enforce_pcfi (fully enabled by default):
         lkrg.enforce_pcfi:
            0 - completely disable pcfi
            1 - enable weak pcfi (no stackwalk)
            2 - enable full pcfi

They are useful e.g. if you want LKRG on the host running VirtualBox. You can 
dynamically reconfigure LKRG to be compatible under such environment by 
disabling MSR verification (sysctl lkrg.enforce_msr=0) and weaken pCFI 
verification (sysctl lkrg.enforce_pcfi=1). You don't need to completely disable 
pCFI (even it is possible) but reconfigure it to not do stackwalk.

Btw. All of the changes are available in the official LKRG repo.

Thanks,
Adam


On Mon, Dec 09, 2019 at 09:06:17AM +0000, Patrick Schleizer wrote:
> 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

-- 
pi3 (pi3ki31ny) - pi3 (at) itsec pl
http://pi3.com.pl
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.