Nanny state operating system restrictions (dmesg) - WARNING post contains cusswords

General Linux Question
1

OK - found this article, it’s old, but still relevant :

So - Ubuntu probably got it from Debian…

I wrote a quick’n’dirty shell script called “de-nannify.bash” :

#!/usr/bin/env	bash
# de nanny-fy this piece of crap : 
# i.e. no longer force users to run sudo to get dmesg output : 
FUCKING=/usr/bin/sudo
$FUCKING sysctl -w kernel.dmesg_restrict=0
CONFILE=/etc/sysctl.d/99-dmesg.conf
if [ -f $CONFILE ] ; then
	echo kernel.dmesg_restrict=0 | $FUCKING tee -a $CONFILE 
else
	echo "some arse hat moved it or changed it or something...."
	echo "$CONFILE does not exist here, here no $CONFILE..."
	exit 1
fi

I just like having swear words replace “sudo” - and I have
alias fucking=sudo
in all my .zshrc files

I used to frequent another Discourse forum and there was a way to make spoilers (e.g. so I could hide the sections with bad language - but I can’t see that feature here…

2

Its a systemd side effect, according to the article

By the way, your script is systemd dependent, so it will fail on some distros.

3

and I don’t care - I run systemd everywhere that’s Linux… the only NIX stuff I have that doesn’t run systemd is my MacBooks, and my Sun Blade 2500 system with Solaris 10 (that I NEVER turn on anyway)… So - that script will also fail on MacOS - but I wouldn’t be stupid enough to attempt running it.

I do very occasionally put checks in my shell scripts to test for MacOS (“darwin”) or FreeBSD…

I guess I need something like this on MacOS too - because that too barfs on “dmesg” without sudo!

I can understand why you’d want this behaviour on server systems… I’m guessing there’s some vulnerability in dmesg that hackers could exploit - but my experience was that dmesg was mostly just a slightly different, and quicker way, of looking at the console log (e.g. cat /var/adm/messages on solaris was nearly the same as “dmesg”).

Also - of note, the “emperor” (only 'cause corporates spend bucketloads licensing it) of Linux Server O/S - Red Hat Enterprise Linux 8 - lets pleb users run dmesg without requiring escalation.

Does this mean either :

RHEL 8 is less secure than Debian 9
- or -
RHEL 8 can’t be exploited through dmesg
???

I rather tend to favour the latter possibility…

also - FreeBSD 12 doesn’t require “sudo dmesg” either :

 x@baphomet  ~  dmesg
---<<BOOT>>---
Copyright (c) 1992-2020 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
	The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 12.2-RELEASE-p14 325282c09a5(HEAD) TRUENAS amd64
FreeBSD clang version 10.0.1 (git@github.com:llvm/llvm-project.git llvmorg-10.0.1-0-gef32c611aa2)
VT(vga): text 80x25
CPU: AMD Turion(tm) II Neo N40L Dual-Core Processor (1497.64-MHz K8-class CPU)
-- snip snip --
(ada4:ata0:0:1:0): READ_DMA48. ACB: 25 00 8d 3b 0c 40 19 00 00 00 01 00
(ada4:ata0:0:1:0): CAM status: Command timeout
(ada4:ata0:0:1:0): Retrying command, 3 more tries remain
arp: REDACTED moved from dc:a6:32:0e:27:e8 to dc:a6:32:0e:27:e9 on epair0b
1 Like