Linux kernel lockdown and UEFI Secure Boot

[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

Comments

You still missed the basic.

[(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.

[mjg59]

And in that scenario you'd either set the boot parameter or the kernel argument, because those things are under your control. If that isn't a feature you want then you don't enable the kernel option. Distributions still have the choice of setting whatever configuration options they want.

Re: You still missed the basic.

[(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.

[(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".

[(Anonymous)]

There might actually be a reason to enable it everywhere if it is compiled in the kernel and that is a developer currently (ab)using features that will get restricted with lockdown, especially if said developer is running his own kernel, didn't set up secure boot and/or is on a distro that doesn't turn this on.

For example lets say such a developer is using distro X which doesn't compile the kernel with lockdown enabled now they get a bug report from someone using distro Y which does have lockdown enabled but from the bug report this might not be clear. The dev can't reproduce it and so tries to get distro Y installed in a VM but this VM has no EUFI secure boot so lockdown doesn't get enabled and thus still can't get it to reproduce.

I think there are 2 ways around this the first is to have lockdown always enabled even on non-secure boot platforms (if it is compiled in the kernel) or have the kernel (or other) logging/errors be explicit in why something got blocked (haven't looked at this so might already be in, hopefully)

Does this make sense or am I just rambling here?

This is reason why lockdown on/off need to be indpedent to secureboot.

[(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.

Re: This is reason why lockdown on/off need to be indpedent to secureboot.

[mjg59]

You're able to do both.

So basically it just restricts the owner of a device?

[(Anonymous)]

Based on your explanation I can only see that it restricts the owner of a device (usually he is the only root, otherwise you would have other things to worry than secure booting a machine anyway...). If this is done solely in the interest of security (of whom?) then there should be a way to disable vendor keys on a device that I own. I don't see how I should be able to trust UEFI secure booot either, it is just another binary blob that a user is forced to trust without open source.

Control

[(Anonymous)]

Hi Matthew.

One of the problems i guess is some just don't want Linux to be good at things like secure boot or DRM ... Now the question i guess is can you blame them?

Re: Control

[(Anonymous)]

The good news is that with Restricted Boots and Kernel Lock The User Out, the user will no longer have to worry about hypothetical malware, because the OS will BE malware.

Here we go again.

[(Anonymous)]

More bullshit masking as security that will help eliminate general purpose computing and lock the user out of his own device.

Who is pushing this? I mean, really? Do you still work for Rat Crap and what do they have invested here?

Re: Here we go again.

[mjg59]

Shim guarantees that you are able to run whatever software you want to on your device

Re: Here we go again.

[(Anonymous)]

As long as Microsoft keeps signing it?

You're not making much sense

[(Anonymous)]

You're saying: "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."

If I understand your article, disabling UEFI secure boot automatically disables lockdown mode (and if not, why not?), so why do you need another kernel with lockdown disabled by default to be shipped? And you really think that a user is going to be able to distinguish between two official kernels, both shipped by the distributor? Why would an attacker not force that kernel to be booted when he gets control over the machine?

Having a command line parameter to disable lockdown would make it obvious both in the journald logs or in /proc/cmdline. Part of me thinks though that user friendliness is not your goal here, only providing some fuzzy feelings of "magic" security that can be withdrawn at any time if the user does "naughty" things.

Re: You're not making much sense

[mjg59]

so why do you need another kernel with lockdown disabled by default to be shipped?

If you have the patch that sets default lockdown policy based on secure boot state, you don't. If you don't have that patch, you do.

Why would an attacker not force that kernel to be booted when he gets control over the machine?

Because it wouldn't be signed.

Having a command line parameter to disable lockdown would make it obvious both in the journald logs or in /proc/cmdline.

Both of which could be compromised after an attacker adds the option and livepatches the kernel.

Re: You're not making much sense

[(Anonymous)]

"Because it wouldn't be signed."

Here is the thing if you are using the shim to start mok you are depending that nothing ever signed by Microsoft third party KEK has been compromised and if it has the dbx has been updated to block it. So this arguement that attacker will not be able to use a different so it is possible that attacker might be able to start a unsigned kernel using something that is already signed that is compromised.

This is the attack surface area problem. Reason why suggesting use MOK to disable secureboot to disable lock-down is invalid in a lot of cases as well.

"Both of which could be compromised after an attacker adds the option and livepatches the kernel."

The signed lockdown kernel might be broken because someone has played with linux kernel boot parameters that are not secure by UEFI. It would really make sense if kernel boot parameters were required to be signed by something. Also system accepting compromised signed boot loader from someone might also see you signed lockdown kernel livepatched.

The reality here is without taking over the PK and installing distribution own KEK that the distribution can control booting a kernel with lockdown enabled is mostly a false sense of security we can depend on compromised signed parts turn up at time point. To reduce risk of compromised signed parts requires limiting installed KEK and taking over PK.

There is no reason why a non lockdown kernel cannot be signed with a different KEK if user decides not to enrol that KEK then it will not work.

There is another reason why you only want to boot signed parts. It called validation. A non lockdown kernel is just as at risk from storage media failure as a lockdown kernel. Problem a signed kernel will detect if you have a disc failure on your hands effecting the kernel. Why the kernel will not pass signature check.

UEFI Secureboot is not just about securing the boot process. Its about validating the files loaded to make sure they have not been damaged. This damaged does not need to be done by an attacker this damage can be done by general hardware failure. So not providing a signed version of a non lockdown kernel you are leaving person open to hardware issues that would have been detected if the kernel had signed and validated by UEFI secureboot.

Yes UEFI should support less trusted KEKs. So you enrol less trusted KEK depending on the EFI configuration this could require user approval to continue boot.

Secureboot validation has a role even without lockdown. Problem is UEFI does not provide a clean interface so throws the baby out with the bath water when you disable secureboot.

Re: You're not making much sense

[(Anonymous)]

You are the one that said in this blog post that to work around situations where lockdown would cause problems the distributions will have to ship two kernels. I'm guessing (hoping) that both kernels would be signed otherwise the users will not be able to run Linux on machines where secure boot cannot be disabled because it will make the system easy to hack. So I don't understand your first 2 replies, unless you are trying to be obnoxious.

On your last reply: how can you disable the printing of the command line at boot time of a signed kernel? Like I've said in the thread's title, you're not making too much sense, and when people point to faults in your logic you just come back with more nonsense.

Looking for a Forced EFI Variable Storage Reclaim Method.

[(Anonymous)]

Matthew,

In the pass you talked about EFI Variable Storage Reclaim in UEFI.

I using Phoenix Secure Core 2.2.3. I rolled Bios back in T/S an issue. Tried to roll it forward later but could not. EVSA Exhausted out of space. I've rebooted to the machine many times. Reclaim of EFI variable space does not seem to happen.
If tell the Dosflash or ShellFlash64 to flash my Capsule is falls thru because of the error. I add a /cvar option to clear variables but I don't think thats executed because it must first check security of a capsule that wasn't loaded because of the error. Plus clear isn't the same thing as reclaim in my mind.

I've been search for a clear method to force the reclaim process to enage and clean up the EFI Variable space. I found one method on Count Chu blog post from 2014. "ToolB.EFI". But he never list the the souce of the tool or a copy of it for download.

I've seen some of your posts too on the matter. I'm noted today something was done in linux kernel 3.9.7 too with regard to proper report of EFI variable free space in "EFI.C". And it made it in that kernel.

Do have any method that would force the reclaim function to engage. From Linux? From Shell64?

Re: Looking for a Forced EFI Variable Storage Reclaim Method.

[mjg59]

Try creating a variable in the kernel, and if that fails reboot and try again - if it still doesn't work then I'm afraid I have no idea.

User vs Distribution

[(Anonymous)]

So, one of your arguments from this post is that there is no way to enforce the kernel cmdline if booted as an EFI executable, but I am doing exactly that since quite some time: I roll the kernel, initrd and cmdline into one EFI binary and then sign that.
AFAIK this prevents anyone from changing the cmdline (please correct me if I am wrong). I think I even learned about this possibility from this very blog :)

However, I think I realize why this "doesn't count" for your argumentation: It would be highly impractical for a distribution to ship this signed blob, as the initrd is usually generated on the users system and the cmdline might also need to account for the users individual setup (root partition or mount arguments at least).
So from a Distributions perspective I want lockdown linked to UEFI because then I can sign this lockdown-enabled kernel, ship it, and guarantee to every user that - if secure boot is on and my keys are enrolled in the firmware - whatever kernel or OS may have been booted or chainloded into, it was signed by me and hadn't be tampered with.

I already see a problem with this: How can the user check if secure boot is actually enabled? If someone managed to compromise the system and turn secure boot off (for example by using shim), they could just boot a system that makes it look like secure boot is enabled.
But this is not my main problem with the patch:

Currently, I am using my distributions prebuilt kernel, as I've had no need for custom kernel options since a long time. I also use secure boot to verify my kernel+initrd+cmdline, as mentioned earlier. I don't really trust the proprietary implementation of it, but it's better than not using secure boot. Everything besides the UEFI boot partition is encrypted, so I "use" this encryption to further verify my boot chain. I know that it's theoretically possible to tamper with an encrypted disk without knowing the encryption key, but again better than nothing.
So I really don't want to disable secure boot, but I might want to disable lockdown (and I can imagine that there are more people who want that than just me). Maybe I want to chainload into something unsigned, but I (sufficiently) trust it because it comes from my encrypted disks.
But if my distribution enables the lockdown option as is, I would have to build my own kernel from now on, until possibly forever. I might even have to maintain my own patch set if I want to leave lockdown available as a cmdline option, but not tie it to secure boot!
That, or the distribution still would have to ship two kernels: One with lockdown tied to secure boot, signed; one with lockdown not tied to secure boot, unsigned.

So, this might actually be a user vs distribution thing. The user wants to disable lockdown without disabling secure boot, but the distribution wants to be able to give guarantees to other users (or maybe other software vendors).

As a user, I don't want to accept the lockdown patches as is. But I think there is another way to solve this, which might be acceptable to Distributions: The distribution ships a tiny signed bootloader that enforces the lockdown argument on the cmdline. The kernel is then signed in a different way, so it can't be booted directly with secure boot but only via the bootloader. There is still an amount of work needed for this (mainly signing the kernel in this "different way"), but it probably beats shipping two kernels, one with a possibly out-of-tree version of lockdown. And I would definitely prefer this over rolling my own kernel from now ;)

Another tiny thing: If the current lockdown patches allow for lockdown to be disabled with alt-sysrq-x during runtime, wouldn't this invalidate all the efforts of lockdown? Say I boot a signed Fedora, disable lockdown, then somehow chainload into a modified Windows which sees secure boot is still active?

When it all started ...

[(Anonymous)]

When it all started ... https://www.phoronix.com/scan.php?page=news_item&px=Kernel-Lockdown-Patches
[Kernel Lockdown Patches Published (LOCK_DOWN_KERNEL) - 17 Nov 2016]

Re: When it all started ...

[(Anonymous)]

Also if you go back to 2016 the question of how to disable lockdown without dropping all validation was raised.

Basically from Nov 2016 to now nothing has been done to make sure a person can still boot a signed kernel that will be validated that does not have lockdown.

So this is a case that people working on lockdown have been one tracked. The answer that to disable lockdown is run unsigned kernel was not acceptable in 2016 and is still not acceptable. Go back work out a solution where all boot kernels with or without lockdown are signed. Even if this means remaking the shim.

secure boot kexec not trusting secondary trusted keys

[(Anonymous)]

Hey Matthew,
I've reported a bug in the (your?) kexec secure boot implementation with regards to custom platform keys in march: https://bugzilla.redhat.com/show_bug.cgi?id=1554113, but unfortunately have not received any responses (even though another user confirmed the bug).

Could you please have a look at it?

Re lockdown mode

[(Anonymous)]

I don't think all lockdown features should be enabled on UEFI secure booted systems. On laptops, one can, for example, have OPAL self encrypting drives that are unlocked transparently before the OS (or the bootloader for that matter) have any chance of knowing about it. In this case, the blocking of hibernation is not needed since the resume partition is encrypted.
Also in the case of laptops, some power management functionality is needed that can only be accessed through MSR and other unorthodox methods. This makes it so that laptop owners have two choices: either disable secure boot and have a full-featured laptop or enable secure boot and have a crippled laptop. I think a third choice would be a generous offer to laptop users to be able to have the most secure system possible while retaining important laptop functionality.

Revoking/blacklisting pre-lockdown kernels

[(Anonymous)]

I understand that some distro's kernels are signed with shim's built-in key. Does that mean pre-lockdown shims using built-in keys would have to be blacklisted in Secure Boot's dbx? Likewise whenever arbitrary code execution vulnerabilities are found in boot loaders/managers, kernels, or modules signed with shim's built-in key, do distros release a new shim with a new built-in key and blacklist the previous shim in dbx? If this was not done, then attackers could use the previous shim and vulnerable/non-locked-down components to bypass Secure Boot.

Given the number of distros out there with their own shim, as well as the fact that vulnerabilities are continuously being found and fixed, users would have to continuously blacklist shim's from all distros in order to stay safe. Is this really the case right now?