Proposal: Enabling DMESG_RESTRICT for Groovy Onward

[Seth Forshee]

On Wed, Jun 17, 2020 at 12:40:36PM +1200, Matthew Ruffell wrote:
> Hello!
> 
> I am proposing that we enable the CONFIG_SECURITY_DMESG_RESTRICT [1] feature by
> default for Groovy onward.

Seems like the discussion on this has stalled. I checked with the
security team and they are +1 on this, so I went ahead and made the
change in our 5.7/5.8 kernel trees. It's likely to be a couple of weeks
before we land one of these in groovy-release, so hopefully that will
give enough time to at least update /usr/bin/dmesg.

Thanks,
Seth

> 
> 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
> 
> -- 
> ubuntu-devel mailing list
> ubuntu-devel at lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel