I believe this fix causes a regression with NoteBook Fan Control (NBFC) as lifting the kernel lockdown was used as a workaround to enable NBFC to control fan speed. See https://github.com/hirschmann/nbfc/issues/414#issuecomment-354274657 and https://github.com/hirschmann/nbfc/issues/472
Would there be another workaround than "simply" disable UEFI secure boot? ** Bug watch added: github.com/hirschmann/nbfc/issues #414 https://github.com/hirschmann/nbfc/issues/414 ** Bug watch added: github.com/hirschmann/nbfc/issues #472 https://github.com/hirschmann/nbfc/issues/472 -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1851380 Title: root can lift kernel lockdown Status in linux package in Ubuntu: Fix Released Status in linux source package in Xenial: Invalid Status in linux source package in Bionic: Fix Released Status in linux source package in Disco: Fix Released Status in linux source package in Eoan: Fix Released Status in linux source package in Focal: Fix Released Bug description: SRU Justification Impact: The kernel lockdown support adds a sysrq to allow a physically present user to disable lockdown from the keyboard. A bug in the implementation makes it possible to also lift lockdown by writing to /proc/sysrq-trigger. Fix: Correct the logic to disallow disabling lockdown via /proc/sysrq- trigger. Test Case: Write "x" to /proc/sysrq-trigger. When working properly there should be no messages in dmesg about lifting lockdown, and lockdown restrictions (e.g. loading unsigned modules) should remain in effect. Regression Potential: Anyone using /proc/sysrq-trigger to disable lockdown will no longer be able to do so. Implementation bugs could prevent use of the sysrq from the keyboard from disabling lockdown, but this has been confrimed to still work with the fix in place. --- 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 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1851380/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
