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

[Guest]

You have it all wrong, you replied to something I didn't even mention.

I agree that security by obscurity is bad business and that is why I did NOT mention it above. There are other, perfectly valid reasons that dmesg SHOULD be hidden by default, like privacy.

"Remember, that all the good rootkits benefit by learning about the system they invade, the dmesg is one of the sources they use before infection." - that's a security justification you've provided there, and it explicitly states that the system will somehow be insecure if you don't hide some small piece of information. That's pretty much the definition of security by obscurity.

You used the word privacy, but didn't provide any examples to highlight why user access to dmesg would be bad for privacy.

[bash2bash]

My quote is not about security by obscurity but its obvious you are wrong and you won't admit it, so this argument is /dev/null

In essence, if dmesg should have a justification for being readable by everyone not the over way around.

"Remember, that all the good rootkits benefit by learning about the system they invade, the dmesg is one of the sources they use before infection." - that's a security justification you've provided there, and it explicitly states that the system will somehow be insecure if you don't hide some small piece of information. That's pretty much the definition of security by obscurity.

You used the word privacy, but didn't provide any examples to highlight why user access to dmesg would be bad for privacy.

[Luke_Wolf]

Security theater at it's best.

To exploit this requires a compromised user account and having a kernel exploit to actually do anything. If they're that far you're already screwed.

Meanwhile the information is very useful to have for users to diagnose what's going wrong with their machine.

[szymon_g]

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

[Grogan]

Seeing dmesg output is useful, for example plugging in a USB device, I like to check to see if it's properly configured. I like to check for errors if something doesn't go right.

I'm not using "sudo".

A dumbed down system makes for dumb users. How can a user even report a problem if they can't see i/o errors and stuff. I'm old school and I've been using Linux for many years. I have helped a lot of people, solve a lot of problems just by looking at dmesg output.

The bullshit I have to circumvent in most distros these days just to have a usable system royally pisses me off. Keep it up, and it will be just like Windows where if you want to get anything done you have to run with elevated privileges.

[DarkFoss]

I'm running Kde-Neon, no need to use sudo just dmesg in a terminal works. I normally use dmesg | grep -i -w -e drm -e amdgpu to see if an error in the current kernel is fixed when running mainline.

[Mangix]

Happy to report I added this in OpenWrt. Not that it matters.

https://github.com/openwrt/openwrt/commit/45219c1c0ff9e896fc626ad3415cf2fe8a3c635d

[aht0]

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

I think I've seen the latter in Linux too somewhere. Probably in Alpine Linux.

[F.Ultra]

Related:

Now create user accounts for your wife and your kids and report back how this is not a problem if any of those accounts executes some nasty code.

[ssokolow]

To be honest, locking down dmesg feels like the Linux equivalent of those The Old New Thing posts about clients trying to report supposed Windows security vulnerabilities that get WONTFIX'd because "they're already on the other side of the airtight hatch" and the fix would require drastic changes.

(The kind of thing where the reproduction instructions often begin with putting a malicious DLL somewhere that requires permissions that already allowed much less convoluted exploits... such as just attacking the EXE being compromised in the first place.)

...in no small part because dmesg is important for efficiently diagnosing things like "Device was plugged into a bad/too-slow USB hub/cable".

Why not just fix it properly by having a sysctl to hide memory addresses from dmesg instead?