Proposal: Enabling DMESG_RESTRICT for Groovy Onward

[Matthew Ruffell]

Hello!

I am proposing that we enable the CONFIG_SECURITY_DMESG_RESTRICT [1] feature by
default for Groovy onward.

I wish to propose that we restrict /bin/dmesg to users within the 'adm' group
only, which will have little visible impact to end users, while closing the
final security gap currently enjoyed by unprivileged users on multiuser systems.

The kernel log buffer is a treasure trove of sensitive information, and we give
it out freely to anyone who asks for it. There have been substantial efforts
upstream to reduce and prevent kernel addresses from being leaked, and usage of
printk with '%p' have largely been removed. This is not enough, as if a system
has suffered an oops, it still outputs functions, their offsets and addresses,
and particularly, the contents of the stack, which usually contains kernel
addresses.

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

Why should users have access to dmesg if they can't access /var/log/kern.log?

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

1) CONFIG_SECURITY_DMESG_RESTRICT=y in the kernel.
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.
3) Add a commented out '# kernel.dmesg_restrict = 0' to
   /etc/sysctl.d/10-kernel-hardening.conf

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.

You can try the proposed changes at home, right now with:

1) sudo chown root:adm /bin/dmesg
2) sudo chmod 0750 /bin/dmesg
3) sudo setcap cap_syslog=ep /bin/dmesg
4) sudo sysctl -w kernel.dmesg_restrict=1

You admin user will be able to access dmesg like normal, and if you make a
unprivileged user, they will see:

$ dmesg
-bash: /usr/bin/dmesg: Permission denied

Let me know your thoughts and concerns.

Note: This is NOT an attempt to remove 'adm' from the default admin user.
Having access to 'adm' as the default user is what makes Ubuntu special and
easy to use, and I wouldn't want to place a breaking change like that on our
community.

Thanks,
Matthew Ruffell
Sustaining Engineering

[1] https://www.kernel.org/doc/html/latest/admin-guide/sysctl/kernel.html#dmesg-restrict