Ubuntu 20.10 Looking At Restricting Access To Kernel Logs With dmesg

[CommunityMember]

I tried this, it was super annoying when you are a pro user / developer.

And, of course, for those individuals on single use systems that one has administrative control over one can create the sysctl override file to change the operational default back to unprivileged, which I would not be surprised to learn that many of those individuals may choose to do.

[Ronshere]

And, of course, for those individuals on single use systems that one has administrative control over one can create the sysctl override file to change the operational default back to unprivileged, which I would not be surprised to learn that many of those individuals may choose to do.

Until that get phased out

[Vistaus]

In my opinion the idea is the right thing to do, I would appreciate that change.

Always nice when people post stuff like this without explaining why they value a change...

[k1e0x]

So what you are saying is.. Ubuntu and other Linux vendors are developing a way to run

chmod 550 /bin/dmesg

Well.. sounds like a serious issue that will take a lot of engineering. I hope they figure it out.. might take them a while.. We might need and entire framework and systemd-dmesg for this.

[ssokolow]

So what you are saying is.. Ubuntu and other Linux vendors are developing a way to run

chmod 550 /bin/dmesg

Well.. I hope they figure it out.. might take them a while..

AFAIK, the underlying syscalls aren't privileged, so an attacker could just bring their own copy of dmesg or call them directly in whatever tool they're cobbling together. This would make calling them a privileged operation.

[k1e0x]

AFAIK, the underlying syscalls aren't privileged, so an attacker could just bring their own copy of dmesg or call them directly in whatever tool they're cobbling together. This would make calling them a privileged operation.

What? You let users install their own software???? What kind of admin are you? heh

No.. This only matters in servers and user writable directories shouldn't be executable.

I don't really see this as something that needs to be fixed on a syscall level. That feels like a heavy hand to me. I'm sure there are probably situations where this becomes a problem. (such as in a container) but perhaps that can be better done on the container level? Again I'm viewing this from sysadmin perspective and not developer perspective.. executing your own code on a production box? no thanks. You can't put in protections for every binary someone could possibly put on there.

There is no "pro user / developers" There is only users and admins. Clearly a dev wrote that.. it is not a thing I assure you they are just users.

[zyxxel]

"the final security gap currently enjoyed by unprivileged users on multi-user systems"

I am willing to bet against that. Any takers?

The article already contained a scope for the claim - access to system log output.

[kindu smith]

it's not a good idea, if you aren't root, dmesg will can‘t be run.

[ssokolow]

What? You let users install their own software???? What kind of admin are you? heh

No.. This only matters in servers and user writable directories shouldn't be executable.

I don't really see this as something that needs to be fixed on a syscall level. That feels like a heavy hand to me. I'm sure there are probably situations where this becomes a problem. (such as in a container) but perhaps that can be better done on the container level? Again I'm viewing this from sysadmin perspective and not developer perspective.. executing your own code on a production box? no thanks. You can't put in protections for every binary someone could possibly put on there.

There is no "pro user / developers" There is only users and admins. Clearly a dev wrote that.. it is not a thing I assure you they are just users.

I don't know if it's the only way to read the kernel message log, but here's an example of why you want to lock it down at the root of things:

cat /dev/kmsg

Your chmod on dmesg wouldn't have prevented that and, if there's a syscall that'll do it, an FFI in a scripting language like Python's ctypes would allow you to call it despite having noexec on all user-writable partitions.

While it doesn't read the kernel message log, here's an example of what I'm talking about which can't be disallowed at the language level without breaking things that would legitimately be run on the server:

python3 <<< "import ctypes; print(ctypes.CDLL('libc.so.6').access('/bin/bash', 4))"

[caligula]

I tried this, it was super annoying when you are a pro user / developer.

Pro user, lmao. How about: alias dmesg='sudo dmesg'