[Bug 1886112] Re: Enabling DMESG_RESTRICT in Groovy Onward

Mon Aug 31 00:20:57 UTC 2020

As per my most recent email to ubuntu-devel, I am marking the changes to
util-linux as Won't Fix.

Relevant mailing list discussion (for future reference):

Ansgar responded on debian-devel mentioning that adding cap_syslog to
dmesg enables the user to clear the kernel log buffer:

https://lists.debian.org/debian-devel/2020/08/msg00121.html>>

> That grants additional rights to the `adm` group that it did not have
> before, for example to clear the dmesg buffer:
>
> $ dmesg --clear
>
> works after adding `cap_syslog` to the dmesg binary whereas it did not
> work before.

Chris Hofstaedtler, the maintainer of util-linux, mentions that granting
such powers to members of adm is more or less unacceptable:

https://lists.ubuntu.com/archives/ubuntu-devel/2020-August/041151.html

> Re-enabling dmesg for the %adm group does not seem to add value for
> Debian now, and granting the --clear (and other) permissions seems
> to be too much.

This was further acked by Steve Langasek:

https://lists.ubuntu.com/archives/ubuntu-devel/2020-August/041152.html

> I agree, and on that basis I also do not believe we should include this
> change to util-linux in Ubuntu.

Because of this, I will no longer pursue opening dmesg up to users in
the adm group, or at least until cap_syslog gets a read-only sister
capability.

Hopefully Ubuntu users won't be too inconvenienced by having to run
dmesg as superuser.

Users can always turn off the behaviour, by setting
"kernel.dmesg_restrict = 0" in /etc/sysctl.d/10-kernel-hardening.conf

** Changed in: util-linux (Ubuntu Groovy)
       Status: In Progress => Won't Fix

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to procps in Ubuntu.
https://bugs.launchpad.net/bugs/1886112

Title:
  Enabling DMESG_RESTRICT in Groovy Onward

Status in linux package in Ubuntu:
  Fix Released
Status in procps package in Ubuntu:
  In Progress
Status in util-linux package in Ubuntu:
  In Progress
Status in linux source package in Groovy:
  Fix Released
Status in procps source package in Groovy:
  In Progress
Status in util-linux source package in Groovy:
  Won't Fix

Bug description:
  [Impact]

  This bug implements the enablement of CONFIG_SECURITY_DMESG_RESTRICT
  feature by default for Groovy onward, proposed to ubuntu-devel:

  https://lists.ubuntu.com/archives/ubuntu-devel/2020-June/041063.html

  The kernel log buffer contains a wealth of sensitive information, such
  as detailed call traces and kernel addresses found in register dumps
  in kernel oops messages.

  Exploit developers and attackers can leverage these information leaks
  to get past KASLR, and they can use the kernel log buffer to get
  instant feedback on their privilege escalation attacks, as failures
  will be shown as further oops messages, which attackers can use to fix
  and tune their programs until they work.

  Currently, if I create a new, unprivileged user on a Focal system,
  they cannot access /var/log/kern.log, /var/log/syslog or see system
  events in journalctl. But yet, they are given free reign to the kernel
  log buffer.

  $ sudo adduser dave
  $ su dave
  $ groups
  dave
  $ cat /var/log/kern.log
  cat: /var/log/kern.log: Permission denied
  $ cat /var/log/syslog
  cat: /var/log/syslog: Permission denied
  $ journalctl
  Hint: You are currently not seeing messages from other users and the system.
        Users in groups 'adm', 'systemd-journal' can see all messages.
        Pass -q to turn off this notice.
  Jun 16 23:44:59 ubuntu systemd[2328]: Reached target Main User Target.
  Jun 16 23:44:59 ubuntu systemd[2328]: Startup finished in 69ms.
  $ dmesg
  [    0.000000] Linux version 5.4.0-34-generic (buildd at lcy01-amd64-014)
  (gcc version 9.3.0 (Ubuntu 9.3.0-10ubuntu2)) #38-Ubuntu SMP Mon May 25 15:46:55
  UTC 2020 (Ubuntu 5.4.0-34.38-generic 5.4.41)
  [    0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-5.4.0-34-generic
  root=UUID=f9f909c3-782a-43c2-a59d-c789656b4188 ro
  ...

  I propose that we restrict access to dmesg to users in group 'adm'
  like so:

  1) Add kernel.dmesg_restrict = 1 to
     /etc/sysctl.d/10-kernel-hardening.conf
  2) Following changes to /bin/dmesg permissions in package 'util-linux'
      - Ownership changes to root:adm
      - Permissions changed to 0750 (-rwxr-x---)
      - Add cap_syslog capability to binary.

  For most users, they will use the initial admin account, which is in
  the 'adm' group already, and will see no impact to these changes. If a
  log scraper type program needs access to dmesg, the user the daemon
  runs as can simply be added to the 'adm' group.

  [Testcase]

  Currently, all users can run /usr/bin/dmesg to view the kernel log
  buffer:

  $ dmesg
  [    0.000000] Linux version 5.4.0-34-generic (buildd at lcy01-amd64-014)
  (gcc version 9.3.0 (Ubuntu 9.3.0-10ubuntu2)) #38-Ubuntu SMP Mon May 25 15:46:55
  UTC 2020 (Ubuntu 5.4.0-34.38-generic 5.4.41)
  [    0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-5.4.0-34-generic
  root=UUID=f9f909c3-782a-43c2-a59d-c789656b4188 ro
  ...

  When the changes are applied, the default admin user will be able to
  view dmesg (since they are in group 'adm'), while new unprivileged
  users will not.

  Test packages are available in the following ppa:
  https://launchpad.net/~mruffell/+archive/ubuntu/lp1886112-test

  $ whoami
  ubuntu
  $ groups
  ubuntu adm cdrom sudo dip plugdev
  $ dmesg
  [    0.000000] Linux version 5.4.0-34-generic (buildd at lcy01-amd64-014)
  (gcc version 9.3.0 (Ubuntu 9.3.0-10ubuntu2)) #38-Ubuntu SMP Mon May 25 15:46:55
  UTC 2020 (Ubuntu 5.4.0-34.38-generic 5.4.41)
  [    0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-5.4.0-34-generic
  root=UUID=f9f909c3-782a-43c2-a59d-c789656b4188 ro
  ...

  $ sudo adduser dave
  $ su dave
  $ groups
  dave
  $ dmesg
  -bash: /usr/bin/dmesg: Permission denied

  [Regression Potential]

  Some users or log scraper type programs may need to view the kernel
  log buffer, or have access to dmesg. In this case, the underlying
  service user would need to be added to the 'adm' group.

  Users have the ability to disable DMESG_RESTRICT by changing
  kernel.dmesg_restrict sysctl in /etc/sysctl.d/10-kernel-hardening.conf
  from '1' to '0', followed by a reboot.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1886112/+subscriptions