Enabling DMESG_RESTRICT in Groovy Onward

Kernel is fix-committed as per:

Mailing list:
https://lists.ubuntu.com/archives/ubuntu-devel/2020-July/041079.html

Commit:
https://kernel.ubuntu.com/git/ubuntu/unstable.git/commit/?id=25e6c851704a47c81e78e1a82530ac4b328098a6

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.

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.]

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.

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.

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.

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.

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

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

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

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

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.

I sponsored the procps changes to Groovy.

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