28

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 if uid != 0).

On most Linux systems, the kernel trusts root so much that it can easily exploit the kernel and gain access to ring 0 at will. However, it is often possible with security tools such as grsecurity, SELinux, etc, to prevent this by reducing root's dangerous abilities, and enforcing these restrictions on the kernel level.

I would like to enumerate a list of methods by which root could exploit the kernel to gain access to kernel mode and ring 0. So far, these are the methods I have thought or learned of by which this could happen, along with potential mitigations:

  • ioperm() and iopl() can set I/O port permissions and can be abused to write to arbitrary regions of memory, including memory where the kernel resides. These syscalls can be disabled by removing them from the syscall table or with grsecurity.
  • Root can just modify the kernel image in /boot or through the block device. A MAC can restrict root's access to both of these.
  • /dev/{k,}mem are designed to allow rw access to arbitrary memory. These can be disabled completely in the kernel config, by using grsecurity, or with a MAC.
  • Some MSRs can be used to write to arbitrary memory. Denying writing to MSRs either by disabling them in the kernel config or with grsecurity mitigates this issue.
  • kexec allows root to select an alternate kernel to boot into. This is an optional kernel feature, so simply compiling the kernel without kexec support is enough to make this a non-issue.
  • sysfs provides low level access to much of the hardware, which can hijack a poorly locked-down BIOS/UEFI on many vulnerable systems to gain ring 0, or even ring -2 access. A MAC can restrict access to /sys, and various tools can detect vulnerabilities in UEFI/BIOS.
  • If root is allowed to load ACPI tables at runtime (DSDT, SSDT, etc), it can cause the kernel to execute AML, which is ACPI bytecode, and change how the kernel behaves and reacts to the hardware it runs on. I know little about ACPI and AML, but this sounds like an absolute recipe for disaster. Disabling loadable ACPI table support in the kernel should mitigate this.
  • Loading malicious kernel modules can directly hijack the kernel. This can be trivially defeated by requiring module signing, or by building a kernel without module support.

Obviously, I will be using principal of least privilege for root, rather than trying to blacklist all the possible ways it can break out of its chains. That doesn't change the fact that it is still extremely useful, and interesting, to understand all the ways it can abuse the kernel's trust.

And so that brings me to my question: Are there any other methods which root can use to gain access to ring 0, without using 0days and without exploiting opsec mistakes, which I have not covered here?

4
  • What is your goal with this? Apr 7, 2016 at 4:49
  • 6
    The goal is simply to understand in what ways root can compromise a system. On my own system, I have root limited quite strictly, but instead of assuming that my own whitelist approach is tight enough, I set out to learn more about the entire topic.
    – forest
    Apr 7, 2016 at 6:42
  • Just to ask you, who will configure SELinux? Who will perform kernel update if necessary? And how he will do so if he is prevented?
    – Fis
    Sep 14, 2019 at 8:57
  • @Fis Pre-isolated root can configure SELinux but, once it is enabled, even root cannot disable it (depending on configuration). For an LSM like SELinux, I believe that's CAP_MAC_OVERRIDE and CAP_MAC_ADMIN.
    – forest
    Sep 14, 2019 at 9:01

2 Answers 2

3

I can think of these:

  • Indirectly modifying kernel image or signed modules by changing update or other system configurations (point update server to yours, add your keys). Or by compromising infrastructure where the updates come from.
  • n-days. syzkaller reports quite a few bugs and some remain unfixed for a while. https://syzkaller.appspot.com/
  • Loading firmware onto a device that can directly interact with RAM (e.g. PCIe, firewire devices).
8
  • I think that n-days are out-of-scope because the question is about an up-to-date system. And loading firmware onto a DMA-capable device requires IO permissions which are explicitly disabled.
    – forest
    Sep 7, 2019 at 6:35
  • Unfixed n-days. Firmware can be loaded through "normal" means by using kernel interfaces, replacing file on storage, changing update configuration.
    – domen
    Sep 8, 2019 at 8:21
  • 1
    Maybe it's the terminology or maybe I'm misunderstanding you. I am talking about publicly known vulnerabilities for which there is no fix yet, so having an up to date system doesn't help. If you look at syzkaller url, I'm confident you could find an interesting use-after-free.
    – domen
    Sep 8, 2019 at 8:55
  • 1
    It could be that you want to enumerate escallations that are there by design.
    – domen
    Sep 8, 2019 at 8:56
  • 2
    Escalations by design is exactly it.
    – forest
    Sep 8, 2019 at 8:57
-7

Root is designed to do whatever he wants on the system! He is the system administrator. He is the boss there. There is no reason to limit him in any way! As there will always be a method to go in somehow - i.e. compile kernel space module, properly sign it and force kernel to load it on next reboot or modify some system files, certificates, whatever I can't see any reason to prevent him to do something.

I would rather recommend you to use less privileged accounts with assigning only necessary privileges and disable direct logins to the root account completely!

24
  • 4
    -1 This is incorrect. Root can be restricted, and regularly is. This doesn't answer the question.
    – forest
    Sep 14, 2019 at 2:54
  • Let us continue this discussion in chat.
    – forest
    Sep 14, 2019 at 9:06
  • Maybe regulrly is but it is completely wrong way.
    – Fis
    Nov 14, 2019 at 5:09
  • What is the wrong way?
    – forest
    Nov 17, 2019 at 22:36
  • Preventing somebody to so something. Better to prevent him anything and allow just things we want allow him.
    – Fis
    Nov 18, 2019 at 1:37

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .