Enabling the kernel's DMESG_RESTRICT feature

[Steve Langasek]

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[1], 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[2]). I brought this up[3] 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
intended protections.

> Kernel address leaks will become even more valuable to exploit authors
> once kernel base address randomization[4] 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...
Name: signature.asc
Type: application/pgp-signature
Size: 828 bytes
Desc: Digital signature
URL: <https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20110525/5c7faf36/attachment.pgp>