Bug 1800859

Summary:	[security] Kernel lockdown can be lifted without physical presence
Product:	[Fedora] Fedora	Reporter:	Hal Murphy <jgukuyvkpy>
Component:	kernel	Assignee:	Kernel Maintainer List <kernel-maint>
Status:	NEW ---	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	rawhide	CC:	airlied, ajia, bskeggs, cbm, fweimer, hdegoede, ichavero, itamar, jarodwilson, jbuchert, jeremy, jglisse, jhaar, john.j5live, jonathan, josef, kernel-maint, linville, masami256, mchehab, mjg59, pbrobinson, Per.t.Sjoholm, peterplatek, rhbugzilla, steved
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:		Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Hal Murphy 2020-02-08 13:06:28 UTC

1. Please describe the problem:

Lockdown is a security feature for the linux kernel which restricts access to some things even for root user. Fedora enables lockdown automatically when secure boot is enabled[1]. It also ships downstream patch (rejected upstream) to allow lifting lockdown with special sysrq keys combination (SysRq+x)[2].

It was recently found that this can be triggered without physical access to the machine, essentially bypassing this security feature [3][4](this was the reason upstream rejected that patch). It affects all distros that ship downstream patch (ubuntu, debian,fedora). Ubuntu decided to drop it already.

This issue affects all fedora kernels that use aforementioned downstream patch including rawhide.

[1] https://fedoraproject.org/wiki/Secureboot

[2] https://src.fedoraproject.org/rpms/kernel/blob/3f0347895c36a37e48c41129cc530ab460ea95a3/f/lift-lockdown-sysrq.patch

[3] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1861238

[4] https://github.com/xairy/unlockdown

Comment 1 Hal Murphy 2020-02-13 07:41:06 UTC

This is now fixed in all active fedora branches (by removing lockdown lifting by sysrq support):

https://src.fedoraproject.org/rpms/kernel/c/7931e3d890b966ab879c1878b4ed31373298978b?branch=master

https://src.fedoraproject.org/rpms/kernel/c/d7d00d12af89d70ff64ba9f4ecf3691c7b8a9453?branch=f31

https://src.fedoraproject.org/rpms/kernel/c/fd6ba4ca25cbb9a39cdac549d18fd8489a9b62ee?branch=f30

You may mark this bug as fixed.

Comment 2 Hal Murphy 2020-02-13 07:45:41 UTC

One remaining thing to do is updating wiki which now serves outdated info about disabling lockdown:

https://fedoraproject.org/wiki/Secureboot#What_is_Secure_boot.3F

Comment 3 Wilhelm Wijkander 2020-02-24 14:48:14 UTC

Do I understand it correctly if this change essentially makes it impossible to get the added security benefit of a signed kernel verified by the shim, while at the same time being able to use programs restricted by kernel lockdown(such as eBPF/bpftrace for example)? Is there a possibility for a middle ground as it existed with alt-sysreq-x previously, without rolling a local kernel?

On a different note, kernel_lockdown(7) in f31 still seems to reference the sysrq workaround.

Comment 4 Hal Murphy 2020-02-25 18:51:47 UTC

I'm not sure but maybe booting with "lockdown=none" in cmdline will disable lockdown without disabling secure boot.

Comment 5 Peter Platek 2020-04-15 22:25:37 UTC

"none" doesn't seem to be an option?
lockdown=       [SECURITY]
                        { integrity | confidentiality }
                        Enable the kernel lockdown feature. If set to
                        integrity, kernel features that allow userland to
                        modify the running kernel are disabled. If set to
                        confidentiality, kernel features that allow userland
                        to extract confidential information from the kernel
                        are also disabled.

Comment 6 Wilhelm Wijkander 2020-04-22 15:56:45 UTC

(In reply to Peter Platek from comment #5)
> "none" doesn't seem to be an option?
> lockdown=       [SECURITY]
>                         { integrity | confidentiality }
>                         Enable the kernel lockdown feature. If set to
>                         integrity, kernel features that allow userland to
>                         modify the running kernel are disabled. If set to
>                         confidentiality, kernel features that allow userland
>                         to extract confidential information from the kernel
>                         are also disabled.

The previous Fedora default was lockdown=confidentiality, which has since been switched to lockdown=integrity in https://bugzilla.redhat.com/show_bug.cgi?id=1815571 allowing the eBPF programs I run to work at least, with Secure Boot enabled.