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
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.
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
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.
I'm not sure but maybe booting with "lockdown=none" in cmdline will disable lockdown without disabling secure boot.
"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.
(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.