In 2019, Most Linux Distributions Still Aren't Restricting Dmesg Access

[Snaipersky]

Seems like the best approach would be to lock it down by default, and make it accessible in a diagnostic boot mode, something between console only rescue mode and secured multiuser mode. I might play around with a runlevel to see how feasible a package or script to deploy such a mode would be.

[trek]

btw, is there any way to restrict ability of a 'normal' user to see the processes owned by root/others? I know Grsecurity used to offer it few years ago, I wonder if I can have something similar now without that patch

mount -o remount /proc -o hidepid=2

see man 5 proc

[F.Ultra]

So many alternatively gifted wanna-be security professionals/researchers here it's mind boggling.

First of all, dmesg can be run only by local users - it's inaccessible remotely.

Secondly, if the malicious actor has a shell on your PC you're already royally f*cked (think key logging, desktop screenshot'ing, traffic sniffing, etc.) and hiding `dmesg` is completely useless.

Thirdly, a LOT of dmesg data/information can be easily fetched from /proc, /sys and by running certain shell commands. Like over 95% of it.

Fourthly, I've been using Linux for over 20 years and I have never heard of a single security/privacy issue related to (the) dmesg (output) being available to non-root users. Not a single f*cking case.

What a dumb mess we have here. LOOOL.

Phoronix commentators never cease to amaze with their idiocy.

For a moment imagine that there are people out there that are not running just single user systems and rethink how all that you just wrote are completely void.

[Weasel]

For a moment imagine that there are people out there that are not running just single user systems and rethink how all that you just wrote are completely void.

For a moment imagine that those people should absolutely not be the default.

[Weasel]

AKA there are more, VB was just one example.

There are "potentially" more, which I don't care about. If there were more they'd give more examples.

[F.Ultra]

For a moment imagine that those people should absolutely not be the default.

Linux is probably on a gazillion to one ratio between servers and single user desktops.

[pdxjohnny]

"All this security madness will lead to one thing, the user will start running lots of things via sudo by default and the net result will be decreased security."

This is a good point. Security vs. usability is a constant battle. If a distro does turn on CONFIG_SECURITY_DMESG_RESTRICT, users could restore the previous functionality via the sysctl.

mkdir -p /etc/sysctl.d
tee -a /etc/sysctl.d/90-security.conf<<<'kernel.dmesg_restrict = 0'
sysctl -p /etc/sysctl.d/90-security.conf

For completeness on the VirtualBox issue, it was fixed in the April 2017 CPU, and issued CVE-2017-3513. As for other examples, I don't have any off the top of my head. Previous work such as the "kptr_restrict for hiding kernel pointers" patch shows that this has been something people have been thinking about for a while. If one wished to find more examples, research on what prompted that patch would probably lead to more instances of leaked addresses. However, regardless of lack of previous examples, it is always possible that an address leak could be added to the kernel or an out of tree module unintentionally. In which case, an author leaking addresses may avoid using %pK, and therefore still leak. Having CONFIG_SECURITY_DMESG_RESTRICT set thus prevents usage regardless of the way it was written to the kernel logs.

[pdxjohnny]

To address https://xkcd.com/1200/. From a kernel hardening perspective, anything
we can do to make it harder for regular users to attack kernel space, that's
good, because even if a service is running as "nobody" and it gets exploited,
the first thing the attacker is going to do is try to elevate privileges to
then attack the user account with email, Facebook, etc. access. One way to do
that is a kernel exploit, which they would have to bypass KALSR to do, and if
they have a leaked address from dmesg (because dmesg_restrict is not set) then
they can use a bug they would have been otherwise unable to use to do that.
Attackers needs a KALSR info leak in order to run the code execution portion of
their exploit, and while dmesg is not the only way they could get that info
leak, it is one possibility, and therefore the secure default is to disable
non-root users access to it.

[aht0]

For a moment imagine that those people should absolutely not be the default.

You get what you pay for. Or more precisely, ones who pay through paying wages to hired devs, get more often what they want. "Those people" are more often backed by corporate money. Which is what most affects development.

So wisely expect Linux future developments in ever-increasing amounts getting dictated by corporate interests. You, simple home user, don't matter, if you get something then because some corporates invest money into development of workstations too. You have you free ride, if you dislike the changes, feel free to switch to alternative OS'es.

On a softer tone. Similar limitations are optional on several BSD's too (more precisely, limiting dmesg to super user and not allowing unprivileged user see any other processes than his/her own). So, it's not just some pointless paranoia by some Linux dev. Poster above brought out very good point about one possible attack vector using dmesg on user level.

[rene]

joining the security by obscurity bandwagon? hold my beer, done: https://youtu.be/HD6D9gNclYI?t=270