[ivlad]

Closing all means for root to access kernel memory is part of hardening. Modern mainstream distros don’t expose /dev/kmem and /dev/mem can be limited to less dangerous pages like MMIO, /proc/kcore can be disabled, to, etc. It goes beyond MAC policies, some functionality is just omitted from the kernel via compile-time config.

[mort96]

But... root can load kernel modules, and kernel modules can write to arbitrary kernel memory, no?

[Cody-99]

Typically 'hardened' builds disable loading kernel modules shortly after boot. Compromising root at some point after this point doesn't guarantee the ability to load additional kernel modules.

[noodlesUK]

You usually can't run unsigned kernel modules if you have EFI secure boot turned on, depending on the way your distribution's kernel is configured.

[mort96]

Right but then we're back to the "it's not my computer any more" problem. Disallowing me from running my own ring 0 code on my own computer isn't an acceptable trade-off.

[nequo]

You can opt in or opt out as you wish. You get to decide whether the added security of only allowing signed kernel modules is the right trade-off for you. Am I missing something here?

[josephcsible]

That's what everyone said about TPM and Secure Boot, and now you can't, e.g., play Valorant without enabling both.

[mort96]

In cases where you can genuinely just flip a switch and get back proper access to the machine I don't mind it that much, but these "we must restrict the user for 'security' reasons" things usually don't stay like that forever.

[nequo]

But this is Linux so you can use a different distribution if your current distro is daft like that.

Or do you mean that certain programs (like one mentioned by sibling) require the switch to be on?

[ivlad]

If it’s me who disallowed “future me” (or someone pretending to be future me because my account was compromised) loading unsigned modules, I don’t see it as a problem.