Proposal: Enabling DMESG_RESTRICT for Groovy Onward

Alex Murray alex.murray at
Thu Jun 18 05:03:09 UTC 2020

On Thu, 2020-06-18 at 03:00:35 +0930, Marc Deslauriers wrote:

> On 2020-06-16 8:40 p.m., Matthew Ruffell wrote:
>> Hello!
>> I am proposing that we enable the CONFIG_SECURITY_DMESG_RESTRICT [1] feature by
>> default for Groovy onward.

This sounds like a great (and long overdue) addition - thanks for
investigating this Matthew!

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

This sounds like a nice and effective way of achieving this - plus since
we now have journald and journalctl (used by gnome-logs and others) this
matches the behaviour seen there as well.

+1 from me!

>> 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]
> Some historical context:
> Marc.

More information about the ubuntu-devel mailing list