Enabling the kernel's DMESG_RESTRICT feature

[Kees Cook]

On Wed, May 25, 2011 at 11:49:45AM -0700, Steve Langasek wrote:
> 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.
> 
> 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.

If you are debugging a "sudo" failure, it's probably not the kernel's
fault. :) If you just need to be root, you can reboot to single user and
examine the kern.log file. If your disks are busted, you can reproduce
after booting single user, etc.

I won't say it doesn't complicate things, but I would like to point out
that everyone else's suggestion for this is to completely remove the values
from the dmesg report itself, rendering it unavailable to any user, even
root.

Systems that are misbehaving or under development can just always run with
the dmesg_restrict bit off. A system that experiences a single unique
failure where the kernel log can never be accessed seems like a very small
corner-case to hold back a benefit to the rest of the distro's users.

> > 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?

I think I've covered this in other emails -- the leaks are intentional and
useful for debugging. Losing them permanently is not sensible.

> > 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!

Right, a fair point, and I think the better approach is what was suggested
in another thread: just change these two files to group "root".

-Kees

-- 
Kees Cook
Ubuntu Security Team