Enabling the kernel's DMESG_RESTRICT feature

[Kees Cook]

On Wed, May 25, 2011 at 06:41:52AM +0200, Martin Pitt wrote:
> Kees Cook [2011-05-24 11:46 -0700]:
> > $ dmesg | grep -m1 text
> > [    0.000000]       .text : 0xc1000000 - 0xc15112a1   (5188 kB)
> 
> Would it be possible to have the kernel just not log the addresses in
> the first place? It seems kind of pointless to make a big effort of

This was debated at length with upstream, and ultimately, they declared
that printk()s should not be filtered at all, and that as a compromise,
DMESG_RESTRICT was created so that all the printk output (dmesg) could
be treated as privileged.

> randomizing these and then yell it out loudly where it lands in any
> kind of log file. People might also have a custom rsyslog
> configuration etc. which we can't even fix on upgrades.

True, this will not be perfect, but education about why dmesg output
should be considered privileged will be the only sane way to handle
non-default upgrades, I think.

We could also send patches to the various syslog implementations to treat
dmesg with 0600 perms, etc.

> So wouldn't it be enough to have the actual addresses somewhere in
> /proc/ in a 0400 file, and just purge them from printk()s?

Everything (in theory) in /proc and /sys is already being filtered using
the %pK kernel-sprintf() modifier. (There are still likely more to be
added, but the bulk of it is done.) So, as root, you can still see these
values. This was already done in Natty, since it disrupted very little.

-Kees

-- 
Kees Cook
Ubuntu Security Team