** Description changed:

+ 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 : 
+ # 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   │         }
+  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
+  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
+  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

-- 
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:
  In Progress
Status in linux source package in Xenial:
  Invalid
Status in linux source package in Bionic:
  Triaged
Status in linux source package in Disco:
  Triaged
Status in linux source package in Eoan:
  Triaged
Status in linux source package in Focal:
  In Progress

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

Reply via email to