Comment 0 for bug 1851380

Echoing "x" into /proc/sysrq-trigger disables kernel lockdown, even though it shouldn't.

If I'm not mistaken, kernel lockdown is meant to create a barrier between root and the kernel that can only be broken with physical access to the system. It is automatically enabled when the system is booted with UEFI Secure Boot, which is the case for me.

This should show the bug:

# echo "x" > /proc/sysrq-trigger
Nov 05 14:58:15 panzersperre kernel: sysrq: SysRq :
Nov 05 14:58:15 panzersperre kernel: This sysrq operation is disabled from userspace.
Nov 05 14:58:15 panzersperre kernel: Disabling Secure Boot restrictions
Nov 05 14:58:15 panzersperre kernel: Lifting lockdown

Note that it first says that the operation is disabled and then performs this operation.
This should only be possible by physically pressing sysrq+x on an attached keyboard.

I'm doing this on 4.15.0-68-generic on Ubuntu 18.04.3 LTS.
I have kernel.sysrq set to 1 - this is important to be able to trigger this bug. (But I don't think it disqualifies this issue as non-security relevant because root can trivially execute `sysctl kernel.sysrq=1`.)

I first learned about this by reading a blog post (https://gehrcke.de/2019/09/running-an-ebpf-program-may-require-lifting-the-kernel-lockdown/), so I'm not the first to notice this behavior (even though this post doesn't say it's a bug).

Looking through drivers/tty/sysrq.c, I guess the problem is caused by this if condition in __handle_sysrq:

 554 │ /* Ban synthetic events from some sysrq functionality */
 555 │ if ((from == SYSRQ_FROM_PROC || from == SYSRQ_FROM_SYNTHETIC) &&
 556 │ op_p->enable_mask & SYSRQ_DISABLE_USERSPACE)
 557 │ printk("This sysrq operation is disabled from userspace.\n");
 558 │ /*
 559 │ * Should we check for enabled operations (/proc/sysrq-trigger
 560 │ * should not) and is the invoked operation enabled?
 561 │ */
 562 │ if (from == SYSRQ_FROM_KERNEL || sysrq_on_mask(op_p->enable_mask)) {
 563 │ pr_cont("%s\n", op_p->action_msg);
 564 │ console_loglevel = orig_log_level;
 565 │ op_p->handler(key);
 566 │ } else {
 567 │ pr_cont("This sysrq operation is disabled.\n");
 568 │ }

Note that `op_p->enable_mask & SYSRQ_DISABLE_USERSPACE` just causes a printk and no change of behavior.

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: linux-image-4.15.0-68-generic 4.15.0-68.77
ProcVersionSignature: Ubuntu 4.15.0-68.77-generic 4.15.18
Uname: Linux 4.15.0-68-generic x86_64
ApportVersion: 2.20.9-0ubuntu7.8
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC1: niklas 2442 F.... pulseaudio
 /dev/snd/controlC0: niklas 2442 F.... pulseaudio
CurrentDesktop: KDE
Date: Tue Nov 5 14:58:33 2019
InstallationDate: Installed on 2015-12-11 (1424 days ago)
InstallationMedia: Kubuntu 14.04.3 LTS "Trusty Tahr" - Beta amd64 (20150805)
MachineType: LENOVO 20E8S00600
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/@/boot/vmlinuz-4.15.0-68-generic root=UUID=67485aa6-c665-4c53-bf41-328307d0cbf0 ro rootflags=subvol=@ quiet splash kaslr i915.alpha_support=1 vt.handoff=1
RelatedPackageVersions:
 linux-restricted-modules-4.15.0-68-generic N/A
 linux-backports-modules-4.15.0-68-generic N/A
 linux-firmware 1.173.11
SourcePackage: linux
UpgradeStatus: Upgraded to bionic on 2018-07-05 (487 days ago)
dmi.bios.date: 09/26/2018
dmi.bios.vendor: LENOVO
dmi.bios.version: JHET69WW (1.69 )
dmi.board.asset.tag: Not Available
dmi.board.name: Intel powered classmate PC
dmi.board.vendor: LENOVO
dmi.board.version: SDK0E50510 WIN
dmi.chassis.asset.tag: No Asset Information
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: None
dmi.modalias: dmi:bvnLENOVO:bvrJHET69WW(1.69):bd09/26/2018:svnLENOVO:pn20E8S00600:pvrThinkPad11e:rvnLENOVO:rnIntelpoweredclassmatePC:rvrSDK0E50510WIN:cvnLENOVO:ct10:cvrNone:
dmi.product.family: ThinkPad 11e
dmi.product.name: 20E8S00600
dmi.product.version: ThinkPad 11e
dmi.sys.vendor: LENOVO