[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

You still missed the basic.

Date: 2018-04-05 10:03 am (UTC)
From: (Anonymous)
"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."

Neither is required. The kernel/bootloader could be on read only media. Like booting from a live disc. A system using a solution like this may be a pre UEFI one.

So no cryptographic or TPM turning lockdown on there is valid cases.

Having to disable validation of kernel to disable lockdown is highly invalid.


Just because Linux distributions mandate lockdown feature does not mean people building their own kernels want lockdown or people doing a development process on a device want to always have lockdown in way.

Allowing distributions to build with lockdown on does not mean that you cannot provide the features to allow kernels to be built with lockdown off.

Also not provide the option for when it safe to have lockdown without secure boot is a mistake as well.

Re: You still missed the basic.

Date: 2018-04-05 10:52 am (UTC)
From: (Anonymous)
Exactly Distributions have the option of setting what ever configurations they have to.

Now a person development a embedded device with UEFI boot with secureboot on only as an option yet is wanting lockdown off for diagnostics if going to be up the creek. These device doing sysrq-x is not a option on lot of them as you don't have keyboard. You have a jtag and that is it.

There is no need to bind UEFI secureboot to lockdown absolutely. Binding UEFI secureboot to lockdown will purely get in way.

Adding MOK is adding an extra that will not be in production device as well.

https://askubuntu.com/questions/769268/unable-to-disable-secure-boot-with-mokutil-in-16-04

Its not like using mokutil --disable-validation is without is absolute failures.

The UEFI secureboot to lockdown link does need to be breakable by kernel build option.

I can understand why its wanted on so that when secureboot is on lockdown is on but you have the usage cases where secureboot is on but you need lockdown off. These cases where you have secureboot on but lockdown off you are normally dealing with boot loader from hell provide by a vendor also you normally have PK and KEKs under your control so not requiring anyone one else approval.

There are two conflicting use cases here. People developing on new boards with horrible vendor bootloader vs the general UEFI PC group attempting to match what Microsoft wants to sign shims. The reality is both groups can be happy if enough kernel configuration options is provided.

Please note how long is mok shim going to allowed due to the fact it allows running unsigned kernels with system set to secureboot. We need to consider that one day the ability to turn verified boot off will not be there. Instead you will have to do what is already required on some development boards of set your own PK and KEK and always have secure boot on.

Basically its a error to be using secureboot as a on/off switch.

Re: You still missed the basic.

Date: 2018-04-09 01:21 pm (UTC)
From: (Anonymous)
Going with UEFI in an embedded system is really overcomplicated. Some industrial boot loaders (u-boot, that may be used as a coreboot payload for Intel for those crazy enough to uses their chips in a embedded context) do the job very nicely without unneeded pain. And avoiding to build dependencies in code between the boot loader and the OS. Aka the UEFI runtime services, that replace the old BIOS "interrupts" that used to provide such services & were abused very early by boot viruses... leading their modern counterpart UEFI to implement secure boot. Complexity over complexity to fix a very bad dependency that is as much as possible avoided elsewhere but Microsoft always relied on.
That's what I call "basics".

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.

Page Summary

Expand Cut Tags

No cut tags