Bug 1599197

Summary: kernel lockdown breaks too much for me
Product: [Fedora] Fedora Reporter: Jason Haar <jhaar>
Component: kernelAssignee: Kernel Maintainer List <kernel-maint>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 28CC: airlied, bskeggs, damianatorrpm, ewk, fweimer, hdegoede, ichavero, itamar, jarodwilson, jgehrcke, jglisse, john.j5live, jonathan, josef, kernel-maint, linville, mailinglists35, mchehab, mjg59, robert.hancock, steved, thomas.mey
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-07-09 08:49:14 UTC 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:
Attachments:
Description Flags
disable lockdown in dracut before resume via sysrq trigger none

Description Jason Haar 2018-07-09 07:54:15 UTC 
Description of problem:

Hi there

Since installing F28 on a new laptop and (apparently) mistakenly choosing UEFI boot instead of old BIOS-mode, I've had a couple of problems

My existing Brother USB printer can no longer be controlled via "scanimage" from sane-backends. That generates a "Lockdown: scanimage: ioperm is restricted; see man kernel_lockdown.7" kernel error

...and just now I went to try out wireguard - a "next gen" VPN solution which has a kernel module. They have a repo for installing it, but it's "wireguard-dkms" built-on-the-fly kernel module fails to load with "Lockdown: modprobe: Loading of unsigned module is restricted" too

"sane-backends" actually comes from Fedora-updates, so frankly Fedora should have enabled "ioperm" to work, and I guess you'd argue Wireguard should somehow figure out how to digitally sign their kernel modules (via dkms? I'd think those two are mutually exclusive?), but as a end-user this is all "too hard" for me (like selinux) - so I just want to shoot it in the head

Can you tell me how I can disable this lockdown "feature"? Some exotic kernel-hack is *not* how my system is going to get hacked - I don't want my system to be military-grade secure if that means I can't do the things I want to do on it

So any hint would be appreciated. Google doesn't seem to find instructions for me (I'm hoping you're not going to say I have to reinstall :-(



Thanks

Jason
Comment 1 Matthew Garrett 2018-07-09 08:49:14 UTC 
You can disable lockdown by disabling secure boot - run

sudo mokutil --disable-validation

and reboot, and then follow the prompts. However, please open a bug against sane-backends - drivers for USB devices shouldn't be calling ioperm(). I'll close this bug since this is working as intended from the kernel's perspective, but thanks for the report of the breakage.
Comment 2 Jason Haar 2018-07-09 19:10:37 UTC 
I ran the mokutil command from the console as root and had to enter a password? I made one up and afterwards rebooted. However - there are no "prompts"...

I am running F28 as a server - non-GUI. I assume these "prompts" are GUI-only? Also the wireguard module failed to load: "modprobe: Loading of unsigned module is restricted" - so Lockdown is still in place

Any more hints please :-)

Jason
Comment 3 Matthew Garrett 2018-07-09 19:19:26 UTC 
The prompts are provided in the system firmware, so if it's a headless device you'll need to use the remote console to confirm them.
Comment 4 Jason Haar 2018-07-09 20:08:43 UTC 
Wow - I see what you mean. That did the trick. After the reboot and weird password challenges I got to disable secureboot and then it came up properly - and now I can load the wireguard kernel module :-)

Thanks!

Jason
Comment 5 Thomas Meyer 2019-09-20 21:05:20 UTC 
For the record you can disable kernel lockdown via sys-rq:
sudo bash -c 'echo 1 > /proc/sys/kernel/sysrq'
sudo bash -c 'echo x > /proc/sysrq-trigger'
Comment 6 Jan-Philip Gehrcke 2019-09-26 14:24:37 UTC 
> For the record you can disable kernel lockdown via sys-rq:
> sudo bash -c 'echo 1 > /proc/sys/kernel/sysrq'
> sudo bash -c 'echo x > /proc/sysrq-trigger'

Thanks for the hint. Is this modification permanent / does it survive reboots? Where is this documented? Thank yoU!
Comment 7 Thomas Meyer 2019-09-26 20:26:05 UTC 
Hi,

no sadly above is not enough. in a running system, this enables the resume to hibernate to disk correctly, but once the system is powered on again and the kernel starts above steps needs to be done before trying to resume the image from disk again.
this is why I did patch dracut a bit. see attached patch.
this is just a hack, as my swap is encrypted anyway.
Comment 8 Thomas Meyer 2019-09-26 20:27:23 UTC 
Created attachment 1619783 [details]
disable lockdown in dracut before resume via sysrq trigger
Comment 9 Mai Ling 2019-11-21 12:24:31 UTC 
(In reply to Thomas Meyer from comment #5)
> For the record you can disable kernel lockdown via sys-rq:
> sudo bash -c 'echo 1 > /proc/sys/kernel/sysrq'
> sudo bash -c 'echo x > /proc/sysrq-trigger'

this no longer works in fedora 31:

Nov 21 14:21:39 DESKTOP-NK8IUMU.mshome.net kernel: This sysrq operation is disabled from userspace.


how do I get kernel lockdown and usable dkms on uefi secure boot *at the same time*, as a regular end user?
Comment 10 Damian Ivanov 2019-12-24 13:29:16 UTC 
I have edited the wiki providing some further information: https://fedoraproject.org/wiki/Secureboot
Comment 11 Robert Hancock 2020-01-06 20:21:49 UTC 
You cannot disable lockdown using sysrq-trigger anymore. You have to hit Alt-SysRq-x on the physical keyboard. This is something that only a physical user is supposed to be able to do, not an automated script.
Comment 12 Hal Murphy 2020-02-08 11:27:23 UTC 
Are you guys aware that lockdown can be bypassed without physical access on fedora and all distros that allow sysrq lift? Ubuntu is dropping their patches.

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

https://github.com/xairy/unlockdown
Comment 13 Damian Ivanov 2020-02-08 13:40:47 UTC 


>>You cannot disable lockdown using sysrq-trigger anymore. You have to hit Alt-SysRq-x on the physical keyboard. This is something that only a physical user is supposed to be able to do, not an automated script.
I have not tested if this is true or to what extend this depends on some variable.
Additionally I am not using Fedora anymore.

>>Are you guys aware that lockdown can be bypassed without physical access on fedora and all distros that allow sysrq lift? Ubuntu is dropping their patches.
I think above comment by RH is supposed to explain that. IMHO even if a malicious program could execute sysrqs what is it supposed to do?
Comment 14 Hal Murphy 2020-02-08 14:53:43 UTC 
(In reply to Damian Ivanov from comment #13)
> 
> I think above comment by RH is supposed to explain that.

Nope, above RH comment says "that only a physical user is supposed to be able to do, not an automated script". That statement was proved false: https://github.com/xairy/unlockdown#method-1-usbip

> IMHO even if a malicious program could execute sysrqs what is it supposed to do?

If malicious program can disable lockdown then what's the point of lockdown in first place? Preventing poor users from using their printers like in this case? That doesn't make sense and is pure security theater.

I opened https://bugzilla.redhat.com/show_bug.cgi?id=1800859