This change was announced on the Clear Linux dev mailing list:
You can subscribe to the Clear Linux mailing list at https://lists.clearlinux.org/mailman/listinfo/dev.
==== What’s Changing ====
We will be setting CONFIG_SECURITY_DMESG_RESTRICT=y for all kernel configs which has an impact on non-root users and containers accessing dmesg. dmesg can still be accessed with root/sudo on the host.
Users should now run
sudo dmesgas opposed todmesg.==== How To Restore Current Behavior ===
CONFIG_SECURITY_DMESG_RESTRICT is equivalent to
sysctl kernel.dmesg_restrict = 1, seen on Kernel Self Protection Project/Recommended Settings - Linux Kernel Security Subsystem
As KSPP says, this helps us avoid kernel memory address exposures via dmesg.When building the kernel, setting CONFIG_SECURITY_DMESG_RESTRICT=y establishes a secure default. If users want to configure their system to keep the current behavior, they can use sysctl to do so.
sudo mkdir -p /etc/sysctl.d
sudo tee -a /etc/sysctl.d/90-security.conf<<<‘kernel.dmesg_restrict = 0’
sudo sysctl -p /etc/sysctl.d/90-security.conf==== Background on CONFIG_SECURITY_DMESG_RESTRICT ====
Address exposures are avoided because non-root users will no longer be able to read dmesg logs. Additionally, CONFIG_SECURITY_DMESG_RESTRICT=y will also disable containers from accessing the kernel logs of the host, even if the user in the container is root.
To gain code execution or modify memory within the kernel, an attacker’s first step is to find an info leak. This is due to Kernel Address Space Layout Randomization (KASLR), which randomizes the location of the kernel machine code on boot. Before KASLR was introduced, it was enough for an attacker to find a vulnerability which gains them code execution to exploit the kernel. With KASLR enabled, proper code execution depends on having an info leak as well (such as address disclosure). Non-JIT Return Oriented Programming techniques require attackers to have knowledge of the addresses of certain instructions within their target known as gadgets. In the case of the Linux kernel, one way for an attacker to acquire the addresses they need is via dmesg. Where address disclosure could come from a printk in the kernel or out of tree module that has been loaded.
Modules and other places in the kernel leaking addresses have been known to be a problem for a while, for instance the “kptr_restrict for hiding kernel pointers”
patchset was targeted at solving this problem as well. However, despite that work it is still possible to leak kernel addresses. CVE-2017-3513 was an instance of this.