LWN: Comments on "Kernel lockdown locked out — for now"

Kernel lockdown locked out — for now

zlynx — Tue, 24 Apr 2018 19:06:26 +0000

Well, recently I wanted to access the DRM debug data. But I can't because of kernel lockdown. I wanted a quick GRUB boot command edit, but instead I had to disable secure boot in the EFI. Annoying.

Maybe I missed finding a Fedora command-line option that would have done it.

Kernel lockdown locked out — for now

mcortese — Tue, 24 Apr 2018 05:22:03 +0000

I can understand that someone values convenience above security and doesn't want to enable neither secure boot, nor kernel lockdown. At the other end of the spectrum, those highly concerned with security will enable both. Somewhere in the middle, someone might want the increased security of lockdown without the hassle of enabling secure boot.

But who will want to go so far as to enable secure boot and then fails to avtivate lockdown?

In other words, who will benefit from lockdown not automatically activated by secure boot?

Kernel lockdown vis-à-vis secure-boot

arekm — Tue, 10 Apr 2018 13:12:57 +0000

"Intel Pumageddon" (google)

Kernel lockdown locked out — for now

niner — Tue, 10 Apr 2018 06:32:20 +0000

We do it the old fashioned way with heavy weight kvm machines and puppet. Kata is certainly very tempting, but you know how it is. The system is running quite well as it is and there's always stuff to keep you busy, like the EU GDPR. So I guess Kata Containers will have some more time to mature till we give it a try :)

Kernel lockdown locked out — for now

pabs — Tue, 10 Apr 2018 03:51:56 +0000

Are you using Kata Containers (formerly Intel Clear Containers) or your own custom mechanism for this?

https://katacontainers.io/

Kernel lockdown vis-à-vis secure-boot

kugel — Mon, 09 Apr 2018 11:01:48 +0000

Also SoCs for Routers (e.g. https://blogs.intel.com/iot/2016/05/18/intel-puma/). I work with those.

Kernel lockdown vis-à-vis secure-boot

excors — Mon, 09 Apr 2018 09:53:12 +0000

Depending on your definition of "embedded", Intel does(/did) make embedded SoCs for tablets etc that use a UEFI BIOS and Secure Boot.

microcode

matthias — Mon, 09 Apr 2018 07:02:01 +0000

The spectre (and meltdown) attacks are designed to work without privileged (UID 0) access. Unprivileged users do not have access to the interfaces that will be locked down, anyway. Therefore it makes no difference for these attacks, whether root is allowed (status quo) or disallowed (lockdown) to access these interfaces.

Kernel lockdown vis-à-vis secure-boot

darwish — Mon, 09 Apr 2018 06:16:05 +0000

Embedded _is_ relevant in that case, and my post was a reply to the lockdown's author (direct) quote in the article claiming that "Without some sort of verified boot mechanism, lockdown is just security theater".

Kernel lockdown vis-à-vis secure-boot

nivedita76 — Mon, 09 Apr 2018 00:22:43 +0000

lockdown is useful without secure boot. I think the point was more that secure boot is not very useful without lockdown.

embedded doesn't seem very relevant in any case, it's not going to have UEFI secure boot in any case. The argument is about whether you should turn lockdown on automatically if secure boot is enabled, which is really only a PC/x86 server thing for the most part.

microcode

ballombe — Sun, 08 Apr 2018 18:59:05 +0000

How does lockdown deals with CPU microcode ? can spectre be used to bypass lockdown ?

Kernel lockdown vis-à-vis secure-boot

bluca — Sun, 08 Apr 2018 17:00:14 +0000

It might be orthogonal, but it is hella useful to have lockdown enabled automatically when secure booting. It's just a few lines. Sure, by all means, put it behind a disabled-by-default kconfig. But why take the feature away? Distros clearly like it and their customers want it, given it's been shipping for years.

Kernel lockdown locked out — for now

Paf — Sun, 08 Apr 2018 15:13:19 +0000

I think the suggestion is that it could further harden an existing VM. So you can still put whatever you want in there and then lock it down. You seem to be imagining a world where the hypervisor comes prelocked or something, but I don’t think that’s what niner is suggesting.

Kernel lockdown locked out — for now

niner — Sun, 08 Apr 2018 15:07:40 +0000

Running multiple operating systems on the same hardware is one use case for VMs. Our's is increased security through compartmentalization. We do not rent out our hardware to other people. We run our own applications consisting of a plethora of inter-operating services and simply assume that none of these services is 100 % proof against intruders. Thus we put them into different VMs with narrow and clearly defined interfaces, so when an intruder finds a hole in one service, it would still be hard to get into the rest of the system. And that's where lockdown could help even without secure boot provided by the firmware.

Kernel lockdown locked out — for now

epa — Sun, 08 Apr 2018 13:17:05 +0000

Isn’t the whole point of a VM that you can run whatever OS and kernel you want? If that choice is removed you might as well offer users a container-based setup where they can have ‘root’ but are really just another user on a large system.

Kernel lockdown locked out — for now

niner — Sun, 08 Apr 2018 11:48:47 +0000

I wonder if virtualization has come up in the discussion. I can imagine lockdown being a good tool to further harden virtual machines. We use the one VM per service model to make it harder for an attacker to spread in case of a breach in one service. Lockdown sounds like something that would make it harder to attack the hypervisor even if the attacker gained root privileges in a VM. No need for secure boot to gain some advantage in that case (assuming the hypervisor is properly protected from the network).

Kernel lockdown vis-à-vis secure-boot

darwish — Sun, 08 Apr 2018 09:13:02 +0000

I agree with Linus that lockdown is really orthogonal to secure-boot.

I've written a number of remote exploits (white-hat; merged in Metasploit), and the ability to modify the boot chain is not as easy as the lockdown authors claim. It might be much easier in the servers world due to extreme PC boot-protocol standardization, but it's hard as hell in the embedded world due to esoteric SoCs, unknown custom-built boot-loaders, and read-only storage.

In these cases, and even without secure-boot, basic kernel hardening features like disabling /dev/mem, /proc/<pid>/mem, /proc/kcore, etc. etc. are __invaluable__ in making the attackers life much harder -- even if they got execute access as UID 0.

Yes, with UID0 the attacker can create a kernel module to re-expose all that, but again this is embedded: (f)init_module() might be removed from the kernel. Even funnier: you might only have a root _shell_ access, but not pure uid 0 binary execution context; and then you find yourself with a busybox having wget and insmod removed ;-) You try to write your exploit ELF, byte by byte, using 'echo' to a tmpfs partition; on a lot of devices this will succeed, but others might have a brain-dead 'echo' version that does not support the necessary "-en" parameters, and so on.

So, honestly, Linus is __absolutely__ right:

"Because as long as the explanation is just some 'you must use secure boot or you've already lost and further security is pointless' hocus-pocus magical thinking, I immediately go 'no, that sounds completely bogus and it makes testing and coverage much worse, we've done other things quite like that without this secure boot tie-in'".