CONFIG_SECURITY_DMESG_RESTRICT

[Kees Cook]

On Wed, Nov 17, 2010 at 10:59:48AM +0100, David Henningsson wrote:
> On 2010-11-16 15:49, Kees Cook wrote:
> >On Tue, Nov 16, 2010 at 01:22:19PM +0000, Andy Whitcroft wrote:
> >>FYI this new security option just dropped into the kernel, for now I
> >>have left it turned off.  I suspect you are in the best position to know
> >>if this is something we should be working towards turning on:
> >>
> >>	# CONFIG_SECURITY_DMESG_RESTRICT is not set
> >
> >I'd like to turn this on, but it will take some education since using
> >"dmesg" will suddenly turn into "sudo dmesg" in instructions everywhere.
> >(Most notably apport, actually.)
> 
> For a significant amount of audio bugs, reading dmesg is crucial to
> be able to solve the bug. My guess is that the ratio is the same for
> other types of kernel bugs.
> Even if we can ask the user for password (which apport sometimes
> does already), we'll still lose the ability for non-sudo users to
> report bugs with good enough information.

Right, but luckily, most single-user system owners are the admin, so they
can just use "sudo" to get the dmesg output.

> The counterquestion is - how security sensitive information do we
> have in dmesg? Why is it a security problem to have it turned on?

When developing a local kernel privilege escalation attack, it helps to
know where in memory certain kernel structures are. Recently Dan Rosenberg
has been working to close off these leaks (many in /proc) but upstream did
not want to restrict what was being reported through dmesg, meaning the
entire kernel syslog needed to be hidden to deal with the sensitive
information that can be leaked there. While restricting "dmesg" doesn't
close all those leaks, it is one of many that need to be closed.

-Kees

-- 
Kees Cook
Ubuntu Security Team