Linux 5.4 Pulls In LOCKDOWN Support For Opt-In Hardware/Kernel Security Restrictions

[tchiwam]

I am wrong in thinking that this is more akin to the now pay for gr patch set than a loss of freedom ?

[starshipeleven]

Kernel lockdown used to be a very invasive and risky procedure that only few vendors would have the expertise to implement.

Yeah sure. Just preventing 99% of the tampering is as simple as disabling the kernel module support and unsafe shit like /dev/mem (both are a kernel compile option) and compiling in the kernel all hardware support modules you need.

Then you sign your kernel image and enforce signature checking with the bootloader. Boom. Device is locked down.

This is where we are heading if you want a system that is at least mostly hackable, and kernel lockdown pushes us a bit further in that direction.

Not really.

[starshipeleven]

I am wrong in thinking that this is more akin to the now pay for gr patch set than a loss of freedom ?

you aren't wrong. This is more or less security hardening.

[intelfx]

Are you guys regularly overwriting arbitrary kernel memory locations and fiddling with the low-level control registers in the CPU?

I do. Not just MSRs but PCH BARs too, and not just any regularly, but every 5-30 seconds. Yeah, dethrottling.

Not saying this patchset is strictly bad (if your vendor was going to lock down your system, they would've done it with or without upstream cooperation), but... say goodbye to rooting cheap (and not so cheap) Android phones, in a few years that it will take contemporary kernels to trickle down to consumer SoC board support packages.

[starshipeleven]

say goodbye to rooting cheap (and not so cheap) Android phones, in a few years that it will take contemporary kernels to trickle down to consumer SoC board support packages.

FYI: This feature protects the kernel itself and hardware registers from tampering.
This feature has nothing to do with privilege escalation of OS processes (which is what rooting does), and afaik all Android vulnerabilities that allow rooting are squarely OS-level vulns, kernel is not involved and not terribly relevant.

[intelfx]

FYI: This feature protects the kernel itself and hardware registers from tampering.
This feature has nothing to do with privilege escalation of OS processes (which is what rooting does), and afaik all Android vulnerabilities that allow rooting are squarely OS-level vulns, kernel is not involved and not terribly relevant.

Not saying that you are or aren't wrong, but if so, then what's the point of LOCKDOWN at all? If something is being restricted in the name of security, it means that there exists (or is conceivable) a class of exploits that become impossible with said restrictions. What are they?

[starshipeleven]

Not saying that you are or aren't wrong, but if so, then what's the point of LOCKDOWN at all? If something is being restricted in the name of security, it means that there exists (or is conceivable) a class of exploits that become impossible with said restrictions. What are they?

I already said it. It's for restricting access to the kernel and to hardware features that root should not need to access. It should avoid privilege escalation from "root" to "kernel" permission level (which is basically god mode) and should make sure that the kernel and the kernel modules are not being replaced with malicious ones, or that the kernel/modules/hardware are not forced in unsafe states by abusing access to things that are not normally needed.

It's usually pushed as part of the trust chain with SecureBoot or the Chromebook's signed boot thing, as it ensures that the system will keep running the kernel you want it to, and that root can't just go and change it. Also because if you aren't validating the booted kernel with a signature then anyone can just tamper with the kernel on disk and then reboot.

Yes it does not sound like much, but that's all there is to it. It's basically reducing root privileges a bit over what is perceived as "system", to ensure that you are running the right untampered kernel, so that it can be trusted more to be doing what it is supposed to do.
As said by the patch author and also by a guy in the first few posts of this thread, some distros (namely Ubuntu) are shipping a similar patch in their kernel and have done so for many years now.

Some more verbose writeup by the patch author https://mjg59.dreamwidth.org/50577.html
And the current (merged) PR commit description http://lkml.iu.edu/hypermail/linux/k...9.1/02235.html
And another article mentioned in the commit description https://lwn.net/Articles/751061/


For the sake of stating the obvious again, all "rooting" methods in Android are abusing OS vulnerabilities to get a process to rise its privilege level from user to root, so they can install "su" binary that will then be used later to execute things as root.
Systems that prevent or try to limit these user-to-root vulnerabilities are flatpak sandboxing, containers and firejail (that are using kernel features like namespaces). I don't know what Android uses.

[archkde]

I already said it. It's for restricting access to the kernel and to hardware features that root should not need to access. It should avoid privilege escalation from "root" to "kernel" permission level (which is basically god mode) and should make sure that the kernel and the kernel modules are not being replaced with malicious ones, or that the kernel/modules/hardware are not forced in unsafe states by abusing access to things that are not normally needed.

It's usually pushed as part of the trust chain with SecureBoot or the Chromebook's signed boot thing, as it ensures that the system will keep running the kernel you want it to, and that root can't just go and change it. Also because if you aren't validating the booted kernel with a signature then anyone can just tamper with the kernel on disk and then reboot.

Yes it does not sound like much, but that's all there is to it. It's basically reducing root privileges a bit over what is perceived as "system", to ensure that you are running the right untampered kernel, so that it can be trusted more to be doing what it is supposed to do.
As said by the patch author and also by a guy in the first few posts of this thread, some distros (namely Ubuntu) are shipping a similar patch in their kernel and have done so for many years now.

Some more verbose writeup by the patch author https://mjg59.dreamwidth.org/50577.html
And the current (merged) PR commit description http://lkml.iu.edu/hypermail/linux/k...9.1/02235.html
And another article mentioned in the commit description https://lwn.net/Articles/751061/


For the sake of stating the obvious again, all "rooting" methods in Android are abusing OS vulnerabilities to get a process to rise its privilege level from user to root, so they can install "su" binary that will then be used later to execute things as root.
Systems that prevent or try to limit these user-to-root vulnerabilities are flatpak sandboxing, containers and firejail (that are using kernel features like namespaces). I don't know what Android uses.

Android uses per-app users and SELinux.

[uid313]

Maybe this is useful for IoT devices.

[Marc.2377]

Not saying that you are or aren't wrong, but if so, then what's the point of LOCKDOWN at all? If something is being restricted in the name of security, it means that there exists (or is conceivable) a class of exploits that become impossible with said restrictions. What are they?

Just to add up to starshipeleven's response: kernel-mode rootkits. A rootkit can subvert the OS kernel, and that enables it to do all sorts of interesting stuff, including modifying OS calls to avoid detection and removal, and sometimes even installing itself to the hardware (BIOS, storage controller firmware, even GPU firmware). Good luck dealing with that.

LOCKDOWN is a series of measures that attempt to make the kernel less vulnerable, or harder to subvert.