Hacker News Reader

Comment by mort96 | Hacker News Reader

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

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.

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.

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.

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?

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.

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?

Yeah, that's one of the ways these "optional" "security measures" often become non-optional. Android is a prime example of a system where this has already happened: sure, you can root your device (if your manufacturer allows you to), but none of the software you need.

Another way is simply for the manufacturer to lock down the bootloader/BIOS and not let you disable "secure" boot, as is also common in the Android world.

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

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.

Reply on news.ycombinator.com