Enabling DMESG_RESTRICT in Groovy Onward

Bug #1886112 reported by Matthew Ruffell
14
This bug affects 1 person
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Wishlist
Unassigned
Groovy
Wishlist
Unassigned
procps (Ubuntu)
Wishlist
Matthew Ruffell
Groovy
Wishlist
Matthew Ruffell
util-linux (Ubuntu)
Wishlist
Matthew Ruffell
Groovy
Wishlist
Matthew Ruffell

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.

Changed in linux (Ubuntu Groovy):
status: New → Fix Committed
Changed in procps (Ubuntu Groovy):
status: New → In Progress
assignee: nobody → Matthew Ruffell (mruffell)
Changed in util-linux (Ubuntu Groovy):
status: New → In Progress
assignee: nobody → Matthew Ruffell (mruffell)
Revision history for this message
Matthew Ruffell (mruffell) wrote :
Revision history for this message
Matthew Ruffell (mruffell) wrote :

Attached is a debdiff for procps on Groovy. It adds a commented out entry to 10-kernel-hardening.conf which users can use to disable the setting if they wish.

Revision history for this message
Ubuntu Foundations Team Bug Bot (crichton) wrote :

The attachment "procps debdiff for Groovy" seems to be a debdiff. The ubuntu-sponsors team has been subscribed to the bug report so that they can review and hopefully sponsor the debdiff. If the attachment isn't a patch, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are member of the ~ubuntu-sponsors, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issue please contact him.]

tags: added: patch
description: updated
Revision history for this message
Matthew Ruffell (mruffell) wrote :

I was thinking about this over the weekend, and I think we overlooked the impact of setting CONFIG_SECURITY_DMESG_RESTRICT in the kernel config has on downstream users of Groovy's kernel, namely when it becomes Focal's HWE kernel.

Focal won't be receiving any patches for /usr/bin/dmesg, so I think it is better to not set CONFIG_SECURITY_DMESG_RESTRICT in kernel config, but to instead set kernel.dmesg_restrict systctl to 1 in /etc/sysctl.d/10-kernel-hardening.conf. This would ensure it only changes Groovy onward, and doesn't cause any regressions for Focal HWE users.

I have emailed Seth Forshee asking to revert the config change.

Revision history for this message
Matthew Ruffell (mruffell) wrote :

I have created patches for both the procps package and the util-linux package which implements the proposed changes.

You can find test packages in the following ppa:

https://launchpad.net/~mruffell/+archive/ubuntu/lp1886112-test

Debdiff for procps: https://paste.ubuntu.com/p/qvmHgMhXSj/
Debdiff for util-linux: https://paste.ubuntu.com/p/SYrK9xrwnP/

I have tested the packages on a Groovy daily build, and the changes function as intended. The default user, who is in the adm group can use dmesg freely, and unprivileged users can no longer access dmesg.

I am looking for feedback about the maintainability of the util-linux patches, particularly about the additional burden it would place on merges performed in the future. My main worry is the additional dependency of libcap2-bin needed to set CAP_SYSLOG on /bin/dmesg.

Revision history for this message
Matthew Ruffell (mruffell) wrote :

I emailed Seth Forshee asking about what happens when Groovy's kernel becomes Focal's HWE kernel, and he mentioned that the kernel team has processes in place to handle config changes, and that it isn't a problem.

So we will go with the more secure by default way, and enable CONFIG_SECURITY_DMESG_RESTRICT in the kernel config.

I rebased the patches for procps and util-linux to the latest versions in groovy and their debdiffs are attached below. Since things are quiet on this bug I will write to ubuntu-devel shortly.

Revision history for this message
Matthew Ruffell (mruffell) wrote :

Attached is a procps debdiff for groovy, which adds documentation to /etc/sysctl.d/10-kernel-hardening.conf and a commented out way to disable DMESG_RESTRICT.

Revision history for this message
Matthew Ruffell (mruffell) wrote :

Attached is a debdiff for util-linux which implements the permission and capability changes to the dmesg binary.

Mathew Hodson (mhodson)
Changed in linux (Ubuntu Groovy):
importance: Undecided → Wishlist
Changed in procps (Ubuntu Groovy):
importance: Undecided → Wishlist
Changed in util-linux (Ubuntu Groovy):
importance: Undecided → Wishlist
Revision history for this message
Matthew Ruffell (mruffell) wrote :

Attached is a rebased debdiff for util-linux, which implements the permission changes to the dmesg binary.

Revision history for this message
Matthew Ruffell (mruffell) wrote :

Wrote to debian-devel to see if upstream is interested in carrying the debian postinstall changes for util-linux: https://lists.debian.org/debian-devel/2020/08/msg00107.html

Revision history for this message
Matthew Ruffell (mruffell) wrote :

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
Revision history for this message
Matthew Ruffell (mruffell) wrote :

As 5.8.0-16-generic has now been released to the -release pocket, CONFIG_SECURITY_DMESG_RESTRICT is now enabled in Groovy. Marking the changes to the kernel as Fix Released.

Changed in linux (Ubuntu Groovy):
status: Fix Committed → Fix Released
Revision history for this message
Brian Murray (brian-murray) wrote :

I sponsored the procps changes to Groovy.

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package procps - 2:3.3.16-5ubuntu2

---------------
procps (2:3.3.16-5ubuntu2) groovy; urgency=medium

  * debian/sysctl.d/10-kernel-hardening.conf:
    - Add documentation for DMESG_RESTRICT feature, and allow users to
      disable by uncommenting kernel.dmesg_restrict=0. (LP: #1886112)

 -- Matthew Ruffell <email address hidden> Thu, 23 Jul 2020 16:59:38 +1200

Changed in procps (Ubuntu Groovy):
status: In Progress → Fix Released
Mathew Hodson (mhodson)
Changed in util-linux (Ubuntu):
status: In Progress → Won't Fix
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers