[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
Page 1 of 3 << [1] [2] [3] >>

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.


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.

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


Date: 2018-04-05 02:21 pm (UTC)
From: (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?
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

Here we go again.

Date: 2018-04-05 10:54 pm (UTC)
From: (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: Control

Date: 2018-04-05 11:03 pm (UTC)
From: (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.

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.

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.


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.

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

You're not making much sense

Date: 2018-04-06 07:20 pm (UTC)
From: (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: 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: You're not making much sense

Date: 2018-04-06 09:46 pm (UTC)
From: (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

Date: 2018-04-07 01:39 am (UTC)
From: (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.
Page 1 of 3 << [1] [2] [3] >>