Untrusted Root makes sense with my current understanding. Reasons:
Quote linux - Methods root can use to elevate itself to kernel mode - Information Security Stack Exchange
When most Linux users hear “root”, they think of the maximum possible privilege on a computer. Some even think that root runs in ring 0. But in reality, root is just a regular user running in ring 3, albeit one which the kernel trusts (many sensitive kernel operations are guarded with checks along the lines of
if (!uid_eq(current_uid(), GLOBAL_ROOT_UID)) return -EPERM;to prevent abuse, which simply returns an error ifuid != 0).
It would be good if we could trap a compromised root account in user space and prevent a compromised root from getting kernel mode access.
This would be useful to protect the virtualizer or perhaps even the hardware.
Quote Linux kernel developer Kees Cook kexec: add sysctl to disable kexec_load [LWN.net] (8 Jan 2014)
The intention is for using this in environments where “perfect” enforcement is hard. Without a verified boot, along with verified modules, and along with verified kexec, this is trying to give a system a better chance to defend itself (or at least grow the window of discoverability) against attack in the face of a privilege escalation.
In my mind, I consider several boot scenarios:
- Verified boot of read-only verified root fs loading fd-based verification of kexec images.
- Secure boot of writable root fs loading signed kexec images.
- Regular boot loading kexec (e.g. kcrash) image early and locking it.
- Regular boot with no control of kexec image at all.
Since that is an old quote, things might have improved by now.
At first sight untrusted root looks pointless since root has write access to maliciously alter the bootloader, kernel image, initial ramdisk (initrd) or any other file on the disk. Therefore at least after reboot, a compromised root could escalate to compromised kernel mode. But this is not always the case:
- In Qubes TemplateBasedVMs the root image (where the bootloader, kernel and initrd and more resides) is writeable but non-persistent after reboot. In other words, a malicious modification for example of the kernel image would be gone after reboot of the TemplateBasedVM.
- Using this verified boot idea the same could be accomplished outside of Qubes TemplateBasedVMs. I.e. the same could be accomplished with Debian. A read-only boot medium using debcheckroot (and more to verify initrd, bootloader and whatnot) could make sure that kernel, bootloader, initrd and all non-auto/non-user files shipped by any packages are verified.
And malware re-starting itself from the user’s home folder might be restricted too.
- GitHub - tasket/Qubes-VM-hardening: Fend off malware at Qubes VM startup
- Dev/VirusForget - Kicksecure
Vulnerable files such as ~/.bashrc or folders such as ~/.config/autostart could be checked and/or restored to known sane versions at early boot time when it is considered that no malware is running yet.
The question is, can we disable all the “easy” (non-kernel exploit) ways to prevent root from getting access to kernel space?
That is before reboot - because root can change bootloader, kernel image, etc. and after reboot changes to bootloader, kernel image, etc. must be undone. That might include enforce kernel module software signature verification [module signing] / disallow kernel module loading by default, disable kexec which we are already doing, and whatnot.
A good starting point might be:
Perhaps it may even be possible to prevent root from modifying the bootloader, kernel image, initrd? Perhaps it could be configured that such changes must happen through use of apt-get? But then additional, malicious /etc/apt/sources.list.d/ sources.list or apt command line parameters to set malicious sources.list might be set. Some restrictions (if even possible) might have to go into separate, opt-in packages or opt-in commands if functionality gets restricted too much (such as packages.debian.org as sources only).