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

[Fernseher]

Enabling secure boot automatically locks down dmesg.
And it locks down other security related things as well (suspend to disk).
I´m glad kernel folks will soon add more lockdowns that also will be available to none secure boot users.
Besides, there is so much more to do to get a reasonably safe machine.
Mandatory access control is such an important mechanism, protect at least your web browser and email client. I love AppArmor. It´s simple and straight forward. Better also protect your PDF reader and favourite virtualizer solution with MAC.
Locking down dmesg won´t stop a serious intruder.
The larger your minefield, the better.

[Fernseher]

idiots don't realize the importance of secure defaults, smart guys know sysctl and fstab and don't rely on defaults
(...)

What about these 2:
net.ipv4.tcp_timestamps = 0
kernel.kexec_load_disabled = 1

proc hidepid could break lot stuff, especially virtualizers I guess? I´d rather block PROC an a per app basis with AppArmor. E.g. granting VirtualBox access and deny for firefox.

[aht0]

idiot! security comes in layers

For once I agree.

[Delgarde]

That's a bad justification - it's security by obscurity. If the kernel can be hacked through userspace processes, just because you know some small piece of information, then that implies bad security design/bugs.

There's nothing wrong with security-by-obscurity as such – denying information to an attacker is always good practice. The problem is in relying on obscurity alone, instead of treating it as just one part of good security process. Bugs happen, so if blocking information in dmesg can prevent an attacker from exploiting a bug that's not been found and fixed, then blocking it doesn't sound such a dumb idea, does it?

[Weasel]

idiot! what has this to do with virtualbox?

Did you even read the article you dumbfuck?

[F.Ultra]

Did you even read the article you dumbfuck?

Oracle's VirtualBox was highlighted as one of

AKA there are more, VB was just one example.

[birdie]

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.

[birdie]

Enabling secure boot automatically locks down dmesg.

Solely depends on your distro, so you're lying:

[birdie@localhost hp]$ id
uid=1000(birdie) gid=1000(birdie) groups=1000(birdie) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
[birdie@localhost hp]$ dmesg | grep -i secure
[    0.000000] secureboot: Secure boot enabled
[    0.000000] Kernel is locked down from EFI secure boot; see man kernel_lockdown.7

[birdie]

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.

Wow, there are some sane people here.

[birdie]

Some notes:

- If dmesg output contains the description of a software or hardware fault, an attacker might in theory use this description to decide how to best attack the system.

- A major part of security is about preventing possible attacks (theoretical attacks), which means that many security measures applied to a machine never get activated/triggered.

- I don't understand why you are using vulgarisms in your posts. You could try to learn to resist the urge to use them, with time.

Wow, so you're insisting on locking down something which is immensely useful for most users only because in theory it can be used to hack a system? Wow. What about other exceptionally good additional security measures like locking down /proc access, so that the user can see only his processes? 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. Oh, and don't get me started on the leaky X.org security model where all windows can have full access to other windows' input (mouse/keyboard/touchpad/etc.). Each time you enter your sudo/su password, everything running in your X session may intercept it. Idiots, so many idiots everywhere.