[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2d66681b-a3e5-3cb0-8f46-d3682a414072@riseup.net>
Date: Fri, 24 Jan 2020 07:13:26 +0000
From: Patrick Schleizer <adrelanos@...eup.net>
To: lkrg-users@...ts.openwall.com
Subject: sysctl vs module parameters / Can sysctl be set before loading the
module? | was: bug: LKRG kills VirtualBox host VMs
Awesome work! Happy to report that VirtualBox host software switched
from instantly aborting a running VM when LKRG was load to that no
longer happening. Will test more and report if there are any issues
after more detailed testing.
sudo modprobe p_lkrg
sudo sysctl -w lkrg.enforce_msr=0 lkrg.enforce_pcfi=1
and then starting a VirtualBox VM worked for me.
Now there is a remaining issue. When LKRG get installed, it will kill
any VirtualBox VMs running at that time.
To avoid that, I tried:
sudo modprobe p_lkrg lkrg.enforce_msr=0 lkrg.enforce_pcfi=1
But LKRG does not seem to support module parameters.
I also tried before loading LKRG to manually set the sysctl. In other
words: try to set LKRG sysctl before loading LKRG. That did not work either.
sudo sysctl -w lkrg.enforce_msr=0
sysctl: cannot stat /proc/sys/lkrg/enforce_msr: No such file or directory
Also settings in /etc/sysctl.d folder are ignored after "sudo modprobe
p_lkrg".
I am asking because I plan to install LKRG by default in Kicksecure and
Whonix-Host (these are Debian derivative Linux distributions).
Kicksecure can be installed on top of an already installed Debian. In
such situations it would unexpected to kill any already running
VirtualBox VMs.
While at the moment it looks like that LKRG only kills VirtualBox VMs
without these settings (lkrg.enforce_msr=0 lkrg.enforce_pcfi=1), I was
thinking that it would be better to not start LKRG without these
settings if VirtualBox is already installed. Maybe better to avoid any
issues with the VirtualBox kernel modules. Just speculation.
How could this issue be solved?
Would it be possible to make LKRG support both, module parameters and
sysctl? Dunno if that would be a lot effort and/or add too much
complexity to the source code.
Or is there a way to set sysctl settings before loading the LKRG kernel
module?
Any other solution?
Kind regards,
Patrick
Adam Zabrocki:
> 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
>
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.
