Bug 1800859 - [security] Kernel lockdown can be lifted without physical presence
Summary: [security] Kernel lockdown can be lifted without physical presence
Keywords:
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-02-08 13:06 UTC by Hal Murphy
Modified: 2020-06-18 15:15 UTC (History)
25 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Type: Bug


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Launchpad 1861238 None None None 2020-02-08 15:25:35 UTC

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


Note You need to log in before you can comment on or make changes to this bug.