Slashdot Mirror
Torvalds Opposes Tying UEFI Secure Boot to Kernel Lockdown Mode (phoronix.com)
An anonymous reader quotes Phoronix:
The kernel lockdown feature further restricts access to the kernel by user-space with what can be accessed or modified... Pairing that with UEFI SecureBoot unconditionally is meeting some resistance by Linus Torvalds. The goal of kernel lockdown, which Linus Torvalds doesn't have a problem with at all, comes down to "prevent both direct and indirect access to a running kernel image, attempting to protect against unauthorised modification of the kernel image and to prevent access to security and cryptographic data located in kernel memory, whilst still permitting driver modules to be loaded." But what has the Linux kernel creator upset with are developers trying to pair this unconditionally with UEFI SecureBoot. Linus describes Secure Boot as being "pushed in your face by people with an agenda." But his real problem is that Secure Boot would then imply Kernel Lockdown mode... "Tying these things magically together IS A BAD IDEA."
Kernel Lockdown protects the kernel.
Secure Boot protects against malware and malicious hardware, as well as teenagers with Linux on USB thumb drives bypassing security altogether.
Together they are supposed to make it impossible to bypass or break the core things, which is supposed to make a computer more secure.
Of course adding security breaks things. Such as open source drivers for hardware for which drivers do not exist. Which means that those needing exemptions to the security will lose both, not just one or the other. Reducing security overall.
Secure Boot protects against malware and malicious hardware, as well as teenagers with Linux on USB thumb drives bypassing security altogether.
Actually, it does none of that. This is one of my peeves with secureboot, it is annoying *and* largely ineffectual.
On malware, yes, it would protect against a certain class of malware: boot sector virus. But then again, a subset. Sure you can't be a kernel, and that does hypothetically give the OS creators a foundation to have some layer that is intact. What if your malware is a patched gdm, sshd, pam, or agetty? Yeah, those would be fine. Windows still has plenty of malware despite being 'Secureboot'. What about replacing /etc/shadow in linux or the SAM db in Windows? Sure, that is also fair game, go ahead and insert your backdoor account with admin privilege.
On malicious hardware, it doesn't do anything, though related technologies can cause UEFI drivers to not execute if not signed. The OS asks the platform if it is secureboot enabled and takes the answer at face value (there's no secure mechanism to vlaidate that the platform isn't lying to you).
As far as Linux or Windows PE on USB thumb drives, again it doesn nothing. A windows or linux install disk can also be a 'rescue' disk. For that matter, secureboot covers neither the initramfs nor the wim file, so make your own privileged install media, it's all good as far as secureboot is concerned. You don't need a custom kernel to make a boot disk.
With that, what are the protections against the general class of replacement hardware/boot configuration/boot media?
Well, the weakest is a BIOS/UEFI/bootloader passwords, which in theory mitigates the chances someone can select their bootable media. In BIOS systems, it is common for USB disk to boot preferentially, so this might not pan out. The typical UEFI boot setup on the otherhand is a bit more specific by usually having a single boot item and that boot item being the machine specific boot partiion GUID and file. However even then I suspect you could probably discern the boot volume guid as non-admin user, and I don't know what UEFI will do if you have removable media with the same GUID as the boot volume. Also, none of this does a damn thing if the attacker could remove the boot media and mess with it offline.
So now we have SED/BitLocker/dm-crypt soultions, which are more hardened. However, by themselves these make automatic reboots impossible, and are thus highly annoying. For another, the keyphrase prompt can be emulated and phished if an attacker has two cracks at your system (one to install a fake prompt using a valid kernel, another to go and glean the captured secret.
At last we come to the most relevant security approach: Trusted Boot. Here you use SED/BitLocker/dm-crypt as above, but rather than prompting for password, you seal the key to TPM PCRs. This allows the system to boot and unlock automatically, but only if the user didn't do anything different (like boot form a different device, or enter f1 setup, or replaced the motherboard). Again at least one potential hole is whether you can spoof a GUID to trick the platform to boot with the same PCR state. another limitation is that generally you have a backup password, and a user could assume if they see the prompt, something innocuous went wrong rather than malicious (e.g. I had a device that went in for warranty repair, and the PCR state was lost forever and so I had to take it on faith the repair center nor the mail system did anything to phish the recovery prompt).
XML is like violence. If it doesn't solve the problem, use more.
That is an argument for having the ABILITY to use secure boot with a locked down kernel (Linus is fine with that). It is not an argument for why the kernel MUST be locked down if you use secure boot. The latter is what others are arguing for without providing Linus a good reason.
UEFI secure boot and Microsoft-mandated secure boot are two different things.
Microsoft took the secure boot specification, which is neutral, and added their own requirements, which aren't. They mandated themselves to have literally as much power as possible, while at the same time leaving to the user as little power to take back ownership of their own machine as it was possible without the world accusing them of taking over the PC market.
It's only "great" if you use that company's EFI support for that particular operating system.
Otherwise, it's a major pain in the ass, and can even block you form installing the OS you may want to use.
Microsoft has been the biggest pusher of this scheme, because it did not want people to be able to dual-boot. They called it a "security" measure, but in fact my system is a hell of a lot more secure if I install MacOS and run Windows in a "bootcamp" or VM.
It's ALL ABOUT corporate lock-in, and not about security at all. Just as HDMI was/is.