[personal profile] mjg59
David Howells recently published the latest version of his kernel lockdown patchset. This is intended to strengthen the boundary between root and the kernel by imposing additional restrictions that prevent root from modifying the kernel at runtime. It's not the first feature of this sort - /dev/mem no longer allows you to overwrite arbitrary kernel memory, and you can configure the kernel so only signed modules can be loaded. But the present state of things is that these security features can be easily circumvented (by using kexec to modify the kernel security policy, for instance).

Why do you want lockdown? If you've got a setup where you know that your system is booting a trustworthy kernel (you're running a system that does cryptographic verification of its boot chain, or you built and installed the kernel yourself, for instance) then you can trust the kernel to keep secrets safe from even root. But if root is able to modify the running kernel, that guarantee goes away. As a result, it makes sense to extend the security policy from the boot environment up to the running kernel - it's really just an extension of configuring the kernel to require signed modules.

The patchset itself isn't hugely conceptually controversial, although there's disagreement over the precise form of certain restrictions. But one patch has, because it associates whether or not lockdown is enabled with whether or not UEFI Secure Boot is enabled. There's some backstory that's important here.

Most kernel features get turned on or off by either build-time configuration or by passing arguments to the kernel at boot time. There's two ways that this patchset allows a bootloader to tell the kernel to enable lockdown mode - it can either pass the lockdown argument on the kernel command line, or it can set the secure_boot flag in the bootparams structure that's passed to the kernel. If you're running in an environment where you're able to verify the kernel before booting it (either through cryptographic validation of the kernel, or knowing that there's a secret tied to the TPM that will prevent the system booting if the kernel's been tampered with), you can turn on lockdown.

There's a catch on UEFI systems, though - you can build the kernel so that it looks like an EFI executable, and then run it directly from the firmware. The firmware doesn't know about Linux, so can't populate the bootparam structure, and there's no mechanism to enforce command lines so we can't rely on that either. The controversial patch simply adds a kernel configuration option that automatically enables lockdown when UEFI secure boot is enabled and otherwise leaves it up to the user to choose whether or not to turn it on.

Why do we want lockdown enabled when booting via UEFI secure boot? UEFI secure boot is designed to prevent the booting of any bootloaders that the owner of the system doesn't consider trustworthy[1]. But a bootloader is only software - the only thing that distinguishes it from, say, Firefox is that Firefox is running in user mode and has no direct access to the hardware. The kernel does have direct access to the hardware, and so there's no meaningful distinction between what grub can do and what the kernel can do. If you can run arbitrary code in the kernel then you can use the kernel to boot anything you want, which defeats the point of UEFI Secure Boot. Linux distributions don't want their kernels to be used to be used as part of an attack chain against other distributions or operating systems, so they enable lockdown (or equivalent functionality) for kernels booted this way.

So why not enable it everywhere? There's a couple of reasons. The first is that some of the features may break things people need - for instance, some strange embedded apps communicate with PCI devices by mmap()ing resources directly from sysfs[2]. This is blocked by lockdown, which would break them. Distributions would then have to ship an additional kernel that had lockdown disabled (it's not possible to just have a command line argument that disables it, because an attacker could simply pass that), and users would have to disable secure boot to boot that anyway. It's easier to just tie the two together.

The second is that it presents a promise of security that isn't really there if your system didn't verify the kernel. If an attacker can replace your bootloader or kernel then the ability to modify your kernel at runtime is less interesting - they can just wait for the next reboot. Appearing to give users safety assurances that are much less strong than they seem to be isn't good for keeping users safe.

So, what about people whose work is impacted by lockdown? Right now there's two ways to get stuff blocked by lockdown unblocked: either disable secure boot[3] (which will disable it until you enable secure boot again) or press alt-sysrq-x (which will disable it until the next boot). Discussion has suggested that having an additional secure variable that disables lockdown without disabling secure boot validation might be helpful, and it's not difficult to implement that so it'll probably happen.

Overall: the patchset isn't controversial, just the way it's integrated with UEFI secure boot. The reason it's integrated with UEFI secure boot is because that's the policy most distributions want, since the alternative is to enable it everywhere even when it doesn't provide real benefits but does provide additional support overhead. You can use it even if you're not using UEFI secure boot. We should have just called it securelevel.

[1] Of course, if the owner of a system isn't allowed to make that determination themselves, the same technology is restricting the freedom of the user. This is abhorrent, and sadly it's the default situation in many devices outside the PC ecosystem - most of them not using UEFI. But almost any security solution that aims to prevent malicious software from running can also be used to prevent any software from running, and the problem here is the people unwilling to provide that policy to users rather than the security features.
[2] This is how X.org used to work until the advent of kernel modesetting
[3] If your vendor doesn't provide a firmware option for this, run sudo mokutil --disable-validation
From: (Anonymous)
Reverse as well.

A program that has been tested and developed with lockdown enabled might go a different code path when something works when lockdown is not enabled.

So developers do need to be able to test with lockdown on and off.

So able to enabled on non secureboot platforms and disable on secureboot platforms are development features for developers.
From: (Anonymous)
The only thing then that would be needed (IMHO) is then that if something errors out/goes wrong due to lockdown being enabled is that it must be clear (in the kernel log probably although a return code might work as well) that it is lockdown that is preventing some action from occuring. Otherwise I expect that a lof of issues in programs might be hard to 'fix'[1] since people might chase down the wrong path.

[1] Note in that case closing the bug report with 'won't fix' with a messafe of 'please disable secure boot/kernel lockdown' would be a "fix" depending on the goel of the progam of course
From: (Anonymous)
Please note I do not class as being able to do both if you have disabled verified boot or use a shim. Lockdown is a Linux kernel feature if person has built own kernel need to be controllable from the built kernel alone.

It is one of the faults of UEFI that the boot parameters is not that protected.

You can do a lot of damage from Linux boot parameters
modprobe.blacklist=modname1,modname2,modname3 this so so bad.

http://ruxmon.com/assets/Uploads/ACPI-implants-Ruxmon-presentation.pdf

There are a lot damage that can be done by what we need to fix on laptops and the like at times.

So really if you remove every way someone can attack the boot process a lot of modern computers will not be able run Linux due to their defects.

I really cannot see why lockdown cannot be a boot parameter and be done with it. If root user should not be able to alter boot parameters that is a issue with UEFI design and boot loader design.

Also this would required thought to be put into how to protect kernel boot loader boot parameters when updating kernels and the like.

Read only boot image with boot loader and kernel and settings you have protected the boot parameters.

Yes the argument against using boot parameters for lockdown has been that an attacker as root user can change them. The fact that boot parameters are not protected is the defect binding lockdown to UEFI secureboot is a hack that does not address the defect.

It should be possible to make setting a new kernel in the EFI from Linux kernel have exactly the same boot parameters or be rejected while running in lockdown mode. To change boot parameters than comes boot into a configuration mode. Fixing this would mean lockdown would never need to check UEFI secureboot mode.
From: (Anonymous)
The missing information: If you build a kernel yourself, you can't sign it with a distro key you don't have.

So, while you have full access to change the setting in menuconfig and disable lockdown; you still have to either enroll your own keys, sign your kernel, and rely on several other measures of trust, or disable secure boot and boot an unsigned kernel you built yourself and take personal responsibility for anything that occurs with your one-off kernel build.

If you take a distro kernel, signed, I agree, passing 'nolockdown' is a foolish idea and turns the whole patchset into security theater.

I recall long ago building a kernel with a preset command line back in the lilo days.

Is there any particular reason that 'lockdown' can't be added to the default command line when it's built as an EFI executable, instead of 'hey look, the secure_boot flag is set'? I'm not a kernel developer so I don't know if the grub commandline is suffixed to the default command line or if it throws out the default and rolls with the user provider kernel command line.

Profile

Matthew Garrett

About Matthew

Power management, mobile and firmware developer on Linux. Security developer at Google. Ex-biologist. @mjg59 on Twitter. Content here should not be interpreted as the opinion of my employer.

Expand Cut Tags

No cut tags