Enabling the kernel's DMESG_RESTRICT feature
steve.langasek at ubuntu.com
Wed May 25 18:49:45 UTC 2011
On Tue, May 24, 2011 at 11:46:48AM -0700, Kees Cook wrote:
> In Oneiric, I'd like to change the default availability of yet another
> long-standing system debugging feature: dmesg.
> Since Linux 2.6.37, CONFIG_DMESG_RESTRICT (/proc/sys/kernel/dmesg_restrict)
> has existed, but the default in Ubuntu has been to leave "dmesg" available
> to unprivileged users (i.e. lacking the CAP_SYSLOG capability, changed
> in 2.6.38). I brought this up in November, but ultimately decided to
> wait until we had more important reasons to enable it by default.
> As we have continued to close kernel address leaks, the kernel syslog
> (dmesg) remains one of the last large places where information is being
> reported. As such, I want to close this off from regular users so that
> local kernel exploits continue to have an even harder time getting a
> foot-hold on vulnerabilities. And, as before, this is a tunable that you
> can change in /etc/sysctl.d/ if you do development work, like getting
> owned, etc. For the average user, this information is not needed.
I think this is a bridge too far. dmesg is a very important tool for
debugging systems, and I am very concerned that this will impair my ability
to troubleshoot kernel problems on my hardware - perhaps under circumstances
where the system is so far gone that 'sudo' doesn't work. Which means I
would probably have to twiddle the sysctl bit, which means I won't get the
> Kernel address leaks will become even more valuable to exploit authors
> once kernel base address randomization lands in the kernel, and I
> want to make sure Ubuntu is prepared, well in advance of the next LTS,
> for this change. When the base address is randomized, "dmesg" must be
> privileged, or else the exactly offset is trivially visible (i.e. of
> the offset from "0xc1000000"):
> $ dmesg | grep -m1 text
> [ 0.000000] .text : 0xc1000000 - 0xc15112a1 (5188 kB)
Why can't we simply change the kernel to not output this line when base
address randomization is in use?
> One unresolved problem is that the local default user (who is part of
> "admin") is also part of the "adm" group, which means these log files are
> visible without additional privileges:
> -rw-r----- 1 root adm 25937 2011-05-24 10:59 /var/log/dmesg
> -rw-r----- 1 syslog adm 0 2011-05-24 11:17 /var/log/kern.log
> (And some system have a historically world-readable /var/log/dmesg that
> should be fixed...) Does anyone see any problems in removing the default
> user from the "adm" group? It seems to almost exclusively only be used for
> log file reading permissions...
Yes, this is a BIG problem. The adm group is there precisely so that admins
don't have to use su/sudo and type a password to look at log files. If I'm
trying to debug a Network Manager problem on a system that uses
network-based authentication, not being in the adm group means I have to
wait for network timeouts before I can look at the logs to figure out what I
need to do to fix my network!
I'd much rather we find a way to fix it so the information *logged* to these
files isn't privileged to the point that it can't be exposed to admins,
instead of gutting admins' ability to make use of these crucial logs.
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek at ubuntu.com vorlon at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 828 bytes
Desc: Digital signature
More information about the ubuntu-devel