11

What's the purpose of things like the modules_disabled and kexec_load_disabled sysctls and the locking down of /dev/mem and /dev/kmem? The idea behind them seems to be to prevent root from taking over the kernel, but I'm not sure why this is useful. If an attacker gets root, don't they pretty much own the machine even without kernel access, by doing things like modifying binaries?

I understand that in combination with Secure Boot, this can keep the kernel in a guaranteed good state, but again, if the whole userspace is compromised, why is this useful?

forest
  • 64,616
  • 20
  • 206
  • 257
Joseph Sible-Reinstate Monica
  • 7,110
  • 3
  • 21
  • 35
  • 1
    I think Kees provided a better explanation of his motivation than I could: https://lwn.net/Articles/580269/ – symcbean Oct 11 '16 at 16:42
  • 1
    I agree with @ant0nisk that it's probably more for every day user protection so that the user doesn't shoot them in the foot. While owning a box only requires root, persistent malware will likely look towards the kernel rather than userspace. – RoraΖ Oct 11 '16 at 19:46
  • In terms of security, it's worth mentioning that it adds an extra layer as well. Most certainly not the first and foremost reason but good to know. – Henry F Dec 17 '16 at 02:32
  • It also has the effect of making any kind of anti virus or memory dumping utility to detect a rootkit much more difficult! – Alex Cannon Mar 04 '18 at 20:11

5 Answers5

6

If an attacker gets root, don't they pretty much own the machine even without kernel access, by doing things like modifying binaries?

Maybe, maybe not. With SELinux, you can restrict access to block devices, even for the root user. So, if your root partition is read-only (and the system is running with OverlayFS to provide for non-persistent modifications), then protecting the kernel from root can guarantee a consistent state on reboot, even if the machine has been compromised at the root level.

Whereas if the kernel is not protected from the root user, you can't have such guarantees.

DepressedDaniel
  • 1,240
  • 6
  • 8
3

Without a verified boot, along with verified modules and kexec you will give to the kernel a better chance to defend itself against attack in the face of a privilege escalation. By default the two features are disabled:

kexec_load_disabled:

A toggle indicating if the kexec_load syscall has been disabled. This value defaults to 0 (false: kexec_load enabled), but can be set to 1 (true: kexec_load disabled). Once true, kexec can no longer be used, and the toggle cannot be set back to false. This allows a kexec image to be loaded before disabling the syscall, allowing a system to set up (and later use) an image without it being altered. Generally used together with the "modules_disabled" sysctl.

modules_disabled:

A toggle value indicating if modules are allowed to be loaded in an otherwise modular kernel. This toggle defaults to off (0), but can be set true (1). Once true, modules can be neither loaded nor unloaded, and the toggle cannot be set back to false. Generally used with the "kexec_load_disabled" toggle.

GAD3R
  • 2,211
  • 3
  • 15
  • 38
  • 1
    There are other risks for attacking the kernel, like in [Methods root can use to elevate itself to kernel mode](https://security.stackexchange.com/questions/119712/methods-root-can-use-to-elevate-itself-to-kernel-mode). – forest Nov 29 '17 at 04:25
1

This is not only for anti-hacking measurements, but also a consistency protection I believe.

Imagine if a user (even root) modified something that he/she shouldn't have in the kernel. It can easily destroy the system. Therefore, it is not only for malware protection (even though kernel vulnerabilities are crucial), but also for system consistency.

However, the root can load kernel modules.

These modules have full-kernel capabilities, although they usually themselves from calling arbitrary functions. See more about this here...

And yes, rooting a machine is equivalent to owning it - no need to hack/access the kernel. (Fun fact: pwn comes from the word own)

Community
  • 1
ant0nisk
  • 211
  • 1
  • 4
1

One such point is virtualization. It is not always that the hardware runs only a single OS. When running virtual machines the kernel of the VM still has access to hardware to some extent or it shares part of its memory with the host.

The prominent example that I remember is the VENOM vulnerability. It used the floppy driver to exit the guest machine. Now, a vulnerable kernel could set kernel.modules_disabled=1 and not load the floppy driver. Moreover, with access to the kernel memory someone might inject the driver without going through modprobe (that would be extremely difficult but not impossible).

grochmal
  • 5,677
  • 2
  • 19
  • 30
  • 1
    Why would that be difficult without `modprobe`? There are well-defined functions in the kernel for loading drivers. If you call those functions (since you have access to kernel memory), you can load the driver that way. – forest Nov 29 '17 at 04:27
-1

To answer the question - perhaps some of these things are actually there to make kernel rootkits MORE difficult to detect and remove. If you believe that you have a kernel or even a user space rootkit, the first thing you want to do is dump the system memory so that you can scan for any unusual code. Well with the kernel blocked off now you can't.

This method of security is similar to what Microsoft has done for years. That is making attacks difficult, and changing things so that specific attacks don't work, but still leaving the system very vulnerable to someone who knows what they're doing. For example, MS removed raw socket support in XP SP2 so that a variety of exploit tools wouldn't work (for the time being).

Alex Cannon
  • 402
  • 2
  • 7
  • You can dump memory by loading a signed kernel module or using DMA. – forest Mar 05 '18 at 03:16
  • Maybe the rootkit won't activate, or will self destruct, or will activate countermeasures if it detects a signed (IE known) memory dumping tool being loaded or if DMA hardware is present in the system. The greatest enemy to an advanced rootkit is a memory scanning tool that is unknown to the rootkit. – Alex Cannon Mar 05 '18 at 04:11
  • In that situation, then allowing more modules to be loaded to dump memory is just as useless. In the worst case though, you could just use JTAG instead of regular DMA hardware. Good lock finding a rootkit that can detect JTAG. – forest Mar 05 '18 at 04:17