I understand that, for security reasons (like address randomization), it makes some sense to not let every user be able to read the kernel's dmesg. Linux allows one to restrict dmesg to the root user using: sysctl -w kernel.dmesg_restrict = 1.

That sysctl forces everyone who wants to use dmesg to prepend sudo, which is a problem for me.¹

I would like something in between. I want some user accounts on my machines to have sudoless access to dmesg, but not daemons like apache or non-users like www-data.

Ideally, dmesg access would be restricted to a certain group (say, adm).

What is the cleanest² way to do this?


¹ While I like sudo in concept, I believe it should be a four-letter word: used judiciously by the wise as a perfect epithet for the rare occasions when nothing else would suffice. Unfortunately, I see people using sudo for many mundane tasks nowadays without thinking twice. Getting people into the habit of overusing sudo is a worse security problem than potential address leaks from the kernel.

² I mention "cleanest", because I suspect that some solutions, like chmod 4750 /bin/dmesg, might have potentially hairy security implications.

Update: I've accepted Ikkachu's setcap solution, but I hope that in future versions of Linux there will be a cleaner, more general answer. Perhaps a third sysctl setting for dmesg_restrict that is between 0 (everybody) and 1 (root only), that would let sysadmins specify trusted groups.

  • 2
    I think that part of the problem with sudo is that it's often used to simply do what you're not supposed to -- become root (as with sudo -s). I think a reasonable entry in sudoers to explicitly allow a specific group to specifically run /bin/dmesg is exactly what sudo is for. – DopeGhoti Nov 15 '17 at 17:17
  • 1
    @DopeGhoti: I agree that allowing a group passwordless access is a reasonable use of sudo, but the problem is people, including me, are getting desensitized to using sudo. I want the need for sudo to be so rare that I notice it. For example, I was just looking at the instructions for a program (youtube-dl) which literally says to use sudo pip ... to install it. This is insane from a security perspective as it runs arbitrary code as root! – hackerb9 Nov 23 '17 at 2:23

If, by "sudoless", you mean you want to be able to just write dmesg or such on the command line, then the simplest solution would be to make a script that calls /bin/dmesg through sudo, and configure sudo to let that happen without asking for a password.

So, something like this:

echo 'username ALL = NOPASSWD:/bin/dmesg  ' >> /etc/sudoers
cat <<'EOF' > ./dmesg
sudo /bin/dmesg "$@"
chmod +x ./dmesg

and then put ./dmesg somewhere in your path.

This works as long as you don't have some other program that needs to be able to read the kernel message buffer directly, without going through /bin/dmesg. But then, setting /bin/dmesg setuid would have the same limitation. Running it via sudo is probably safer than simply running it setuid.

As an aside, changing the permissions on /dev/kmsg doesn't work, even though dmesg tries to read it. It falls back to the syslog(2) system call.

If that's not enough, you might be able to do this with capabilities. The dmesg_restrict sysctl restricts reading the log to processes with CAP_SYSLOG, so we just need to arrange for that to be set.

So, something like this:

# cp /bin/dmesg /bin/dmesg.capable 
# chown .adm /bin/dmesg.capable
# chmod 710 /bin/dmesg.capable
# setcap cap_syslog=ep /bin/dmesg.capable

Users in the adm group should now be able to use /bin/dmesg.capable to view the log.

Though note that capabilities are notorious in that many of them provide ways to circumvent the rest of the access control systems, though granting just CAP_SYSLOG is probably better than running dmesg as full root.

Other options that spring to mind are SELinux, seccomp and just plain old patching the kernel to allow reading the log by a certain group.

| improve this answer | |
  • Thanks, but by 'sudoless', I really meant without sudo at all, not even hidden in a wrapper. There are no other answers, though, so I'm beginning to think this is currently impossible in the Linux kernel. – hackerb9 Nov 23 '17 at 2:00
  • 1
    @hackerb9, right, I thought you just wanted to get rid of the trouble of writing sudo, since you said "users need to prepend it". Hiding it behind a script or a shell function removes that everyday nuisance. And really, per-binary targeted privilege is much better than the wide open do what you like that we commonly have. But of course there's the risk that the program has bugs that allow executing other code. – ilkkachu Nov 23 '17 at 12:33
  • Thank you, Ikkachu, for updating your answer so thoroughly. I think capabilities is probably the best available solution, so I'll accept the answer. – hackerb9 Nov 28 '17 at 13:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.