![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Linux kernel lockdown and UEFI Secure Boot
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
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: You're not making much sense
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.
Because it wouldn't be signed.
Both of which could be compromised after an attacker adds the option and livepatches the kernel.
Re: You're not making much sense
(Anonymous) 2018-04-06 09:46 pm (UTC)(link)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) 2018-04-07 01:39 am (UTC)(link)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.
Re: You're not making much sense
By adding the "quiet" argument?
Re: You're not making much sense
(Anonymous) 2018-04-07 07:06 am (UTC)(link)"Secure Boot can be disabled on all systems running shim."
Can you guarantee that M$ and the OEMs will continue to allow Secure Boot to be disabled on all systems running shim.?
Imagine, if your plan to lockdown the Linux kernel goes through and then M$/OEMs stop allowing Secure Boot to be disabled in all new Win 10 computers, we will have a Google Chromebook clone that's very locked down and unuser-friendly.
.
P S - Intel will not allow Legacy BIOS boot in all her new processors from 2020 onward.
Re: You're not making much sense
It doesn't involve Microsoft or the OEMs, so yes.
Re: You're not making much sense
(Anonymous) 2018-04-07 11:20 am (UTC)(link)Since Jan 2018, you are working for Google. Seems you are trying to lockdown the Linux kernel for the Linux desktop OS like how Google had locked-down the Linux kernel for the Android mobile OS = the average Android users could not do a clean reinstall or re-image of Android or other mobile OS on the mobile devices with a Recovery media, eg microSD card, USB flash-drive or DVD = a closed-off/walled ecosystem, full Google control and Planned Obsolescence.
....... Maybe you are doing this to prepare Google's entry into the world desktop OS market, ie to compete against M$-Windows and Apple-MacOS.
If so, instead of locking-down the Linux kernel, I suggest that Google should just lock-down Software Manager or Google Store and charge sales commission for every non-free program/app installed on a Google-owned Linux desktop OS. Google can also get extra revenue by selling user-data to marketers. Ad revenue would still be rolling in through Google services like Search, Maps, Chrome, Youtube, etc.
Re: You're not making much sense
Re: You're not making much sense
(Anonymous) 2018-04-07 09:19 pm (UTC)(link)When did the lock-down patch's tie-in to Secure Boot happen.? Before or after your involvement at Google.?
Re: You're not making much sense
Re: You're not making much sense
(Anonymous) 2018-04-08 08:22 am (UTC)(link)Thanks for the info.
Red Hat is not very different from Google, ie companies that seek to profit from Linux, eg Red Hat Linux Enterprise/Fedora, ChromeOS/ChromiumOS and Android.
Whatever their developers propose for the Linux kernel should not negatively impact the average Linux users, eg by locking-down their Linux kernel during the install of the Linux distro. The lockdown of the Linux kernel should be opt-in and be separate from the UEFI Secure Boot setting.
Re: You're not making much sense
(Anonymous) 2018-08-20 11:24 pm (UTC)(link)Re: You're not making much sense
(Anonymous) 2018-04-07 08:26 am (UTC)(link)Disable secure boot disable validation on kernel right that is has not been damaged on media. Reality we should not end up in a case with a unsigned kernel if it can be avoided. lockdown need to be independent of if kernel is signed or not.
This could require altering the mok so that it support lower security KEK/MOK entries for auditing solutions with lockdown off.
Basically turning signing off defeats one of the the points of UEFI secureboot that is validating the files loaded to boot from.
"Obviously the one that has lockdown disabled wouldn't be signed, because that would defeat the point."
Basically this idea defeats one of the reasons for secureboot. You need to work out how to-do this without ever turning secureboot off. The may require redesign MOK and working with UEFI standard to add another level of KEK.
1) KEK/MOK set for full secure.
2) KEK/MOK set for validation but what ever is using this is not fully secure and depending on configuration this may require password or proof of physical access.
3) No signed mode for UEFI/MOK configuration only once configured this mode disappaers.
And deprecate the existing shim.
Before you added lockdown to the Linux kernel people had KEK or MOK validation of the Linux kernel and boot loader. Saying unsigned is telling those people to down grade their solution.
Re: You're not making much sense
(Anonymous) 2018-04-07 04:35 pm (UTC)(link)MJG59 said, ""Secure Boot can be disabled on all systems running shim."
I said, "Can you guarantee that M$ and the OEMs will continue to allow Secure Boot to be disabled on all systems running shim.?"
MJG59 said, "It doesn't involve Microsoft or the OEMs, so yes."
.
.
Let me rephrase the question. Can you guarantee that M$ and the OEMs will continue to allow Secure Boot to be disabled on all their new Win 10 computers.?
If Secure Boot cannot be disabled, your proposal to lockdown the Linux kernel with Secure Boot enabled will stop most average users from editing the kernel boot parameters in order to be able to boot a Live Linux USB/DVD, eg those with Nvidia or AMD graphics cards.
AFAIK, shim is only needed to boot non-Windows software(eg Linux) when Secure Boot is enabled, ie shim is not needed when Secure Boot is disabled.
Re: You're not making much sense
Re: You're not making much sense
(Anonymous) 2018-04-07 09:08 pm (UTC)(link)So, you are saying that you can guarantee that M$ and the OEMs will continue to allow Secure Boot to be disabled on all their new Win 10 computers.
Keep in mind that when M$ released Win 10 in 2015, M$ had mandated the OEMs to allow Secure Boot to be disabled at the OEMs' discretion = M$ and the OEMs may one day decide not to allow Secure Boot to be disabled or to lock Secure Boot as enabled.
Re: You're not making much sense
Re: You're not making much sense
(Anonymous) 2018-04-08 08:50 am (UTC)(link)I was referring to the UEFI-BIOS firmware setting for Secure Boot, which is usually accessed by pressing one of the Function keys during startup, eg F2/F9/F10/F12/Delete.
So, you are saying that you can guarantee that M$ and the OEMs will continue to allow Secure Boot to be disabled in UEFI-BIOS setup on all their new Win 10 computers.
I'm aware that shim and mok keys can over-ride M$'s control of Secure Boot when SB is enabled. But this is usually used by tech-geeks, and not by the average users.
Like I said earlier, if Secure Boot cannot be disabled in UEFI-BIOS setup, your EFI-lockdown feature will automatically lockdown the Linux kernel during the install of the Linux distro. This will likely present difficulties to the average Linux users, eg when they need to unlock the kernel and edit the kernel boot parameter.
If Linux becomes harder to operate for the average users, eg with your Linux kernel efi-lockdown feature, M$'s Windows will likely continue to be a Win.
The main advantage of Windows over Linux is its very user-friendliness, esp for computer dummies and the average users. As is known, only about 5% of computer-users are tech-geeks or power-users. It is foolish if Linux caters only to this 5% market, eg the geeky Debian and Archlinux distros are not very popular.
Re: You're not making much sense
Re: You're not making much sense
(Anonymous) 2018-08-21 12:30 am (UTC)(link)