CONFIG_SECURITY_DMESG_RESTRICT

Colin Ian King colin.king at canonical.com
Thu Nov 18 00:26:08 UTC 2010


On Wed, 2010-11-17 at 12:34 -0800, Kees Cook wrote:
> 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.

So are we going to change permissions on files such
as /var/log/dmesg, /var/log/kern.log et al too?

> 
> -Kees
> 
> -- 
> Kees Cook
> Ubuntu Security Team
> 






More information about the kernel-team mailing list