[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

Re: Here we go again.

Date: 2018-04-05 11:11 pm (UTC)
From: (Anonymous)
As long as Microsoft keeps signing it?

Re: Here we go again.

Date: 2018-04-05 11:14 pm (UTC)
From: (Anonymous)
And by that, I mean, they do for now because...temporarily...the user is allowed to turn Restricted Boots off, but we see OEMs removing the ability for the user to manage the keys at all (and locking the hardware into modes that are only compatible with Windows), and Microsoft will eventually come for x86 too.

Re: Here we go again.

Date: 2018-04-06 07:13 am (UTC)
From: (Anonymous)
For Win 8 and new UEFI computers in 2012, M$ mandated the OEMs to allow Secure Boot to be disabled.
....... For Win 10 in 2015, M$ mandated the OEMs the discretion to allow Secure Boot to be disabled.

Recently at end 2017, a few OEMs have begun to sell new Win 10 computers which do not allow Secure Boot to be disabled, eg Acer's S and E series laptops.
....... M$'s ARM-based Surface RT tablet PCs did not allow Secure Boot to be disabled.

Imagine the OEMs start not allowing Secure Boot to be disabled in all their new Win 10 computers = all Linux kernels become locked-down = can only be unlocked by tech-geeks.

P S - Certain OEM Win 8.x/10 computers, eg Acer, Asus and HP, have an obstructive or pro-M$ UEFI-BIOS setting for "select an UEFI file as trusted for executing",(= Linux cannot boot). For the fix, please refer to ...

The above latest(= 2017) OEM laptops, eg Acer E and S series, may have even removed this UEFI-BIOS setting(eg "No bootable device" after installing Linux and cannot be fixed), but may be restored by a new BIOS firmware update from the OEMs = update through Windows only. This was after many complaints from affected users. ...
... Another workaround is ...

Re: Here we go again.

Date: 2018-04-06 09:16 pm (UTC)
From: (Anonymous)
"They don't need to "keep" signing it, signed copies already exist."
Really pull the other one it plays jingle bells.


Anything Microsoft has enabled with their KEK they can disable with a windows update pushing out a update to dbx by windows update that disables it. Yes just claim that the shim has a security fault and disable it. Also the KEK that signs the shim is not the one of the ones you need to boot Windows. Microsoft installs their own OS KEKs as well.

The reality is the shim should only be used for install and after that you should really take control replace the PK and update the KEK list. If system not going to run windows removing the Microsoft KEKs to reduce attack surface area.

Really it does not make very much sense to enable lockdown while depending on shim/mok. Once you have installed own KEK you have control of the dbx and cannot be locked out of the system as simply.

Re: Here we go again.

Date: 2018-04-07 03:06 am (UTC)
From: (Anonymous)
"You're confusing KEK and db, but even so - Microsoft aren't going to blacklist anything that has no security issues, since it would be clear anticompetitive behaviour."

Really the shim and mok current design does have a security issue it allowed booting unsigned.

UEFI design has booting unsigned as an action of EFI setup mode when you deleted the PK or if in firmware you have turned secure boot off.

Tightening security requirements is not anti-competitive behaviour. That is the problem.

You say that we need lockdown in the Linux kernel so the Linux kernel cannot be used as a boot loader to unsigned/unapproved then mok has that feature. To turn off lockdown you suggest using mok switch to boot what ever.

Reality if you are running a Linux kernel without lockdown validation of kernel, drivers and key applications comes way more important so that what you loading is what you think you are loading. At times you will need to perform tasks that lockdown forbids this does not mean that performing those tasks you have to take major risks. Like a distribution locked down repair tool could have a kernel without lockdown to fix common faults but be using IMA heavily to limit is operations so not be a security risk.


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