FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Ubuntu > Ubuntu Kernel Team

 
 
LinkBack Thread Tools
 
Old 11-16-2010, 01:49 PM
Kees Cook
 
Default CONFIG_SECURITY_DMESG_RESTRICT

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.)

-Kees

--
Kees Cook
Ubuntu Security Team

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 11-16-2010, 02:19 PM
Colin Ian King
 
Default CONFIG_SECURITY_DMESG_RESTRICT

On Tue, 2010-11-16 at 06:49 -0800, 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.)

I suppose it will also affect APIs such as klogctl(), e.g. reading the
buffer: klogctl(3, buffer, len);

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



--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 11-16-2010, 02:23 PM
Kees Cook
 
Default CONFIG_SECURITY_DMESG_RESTRICT

On Tue, Nov 16, 2010 at 03:19:11PM +0000, Colin Ian King wrote:
> On Tue, 2010-11-16 at 06:49 -0800, 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.)
>
> I suppose it will also affect APIs such as klogctl(), e.g. reading the
> buffer: klogctl(3, buffer, len);

What is using klogctl()? sysklogd uses the /proc interface (and is
privileged when it does the open).

Note also that this is a sysctl as well, so people can disable the
restriction if they need to.

-Kees

--
Kees Cook
Ubuntu Security Team

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 11-16-2010, 04:15 PM
Kees Cook
 
Default CONFIG_SECURITY_DMESG_RESTRICT

On Tue, Nov 16, 2010 at 07:23:31AM -0800, Kees Cook wrote:
> On Tue, Nov 16, 2010 at 03:19:11PM +0000, Colin Ian King wrote:
> > On Tue, 2010-11-16 at 06:49 -0800, 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.)
> >
> > I suppose it will also affect APIs such as klogctl(), e.g. reading the
> > buffer: klogctl(3, buffer, len);
>
> What is using klogctl()? sysklogd uses the /proc interface (and is
> privileged when it does the open).
>
> Note also that this is a sysctl as well, so people can disable the
> restriction if they need to.

Doing a search in all of main, the following use klogctl(), and already
run as root, already require root, or don't need special treatment:

busybox (root in initramfs)
klibc (root in initramfs)
plymouth (root during init)
powertop (already requires root)
util-linux (already required root for "setterm -msg ...")
valgrind (agnostic: used only as a hook for debugee)

Not running as root:

util-linux (dmesg: what we're trying to deal with)

So, I think this should be a safe change, outside of the educational change
I already mentioned for dmesg itself.

-Kees

--
Kees Cook
Ubuntu Security Team

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 11-16-2010, 06:47 PM
Colin Ian King
 
Default CONFIG_SECURITY_DMESG_RESTRICT

On Tue, 2010-11-16 at 09:15 -0800, Kees Cook wrote:
> On Tue, Nov 16, 2010 at 07:23:31AM -0800, Kees Cook wrote:
> > On Tue, Nov 16, 2010 at 03:19:11PM +0000, Colin Ian King wrote:
> > > On Tue, 2010-11-16 at 06:49 -0800, 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.)
> > >
> > > I suppose it will also affect APIs such as klogctl(), e.g. reading the
> > > buffer: klogctl(3, buffer, len);
> >
> > What is using klogctl()? sysklogd uses the /proc interface (and is
> > privileged when it does the open).
> >
> > Note also that this is a sysctl as well, so people can disable the
> > restriction if they need to.
>
> Doing a search in all of main, the following use klogctl(), and already
> run as root, already require root, or don't need special treatment:
>
> busybox (root in initramfs)
> klibc (root in initramfs)
> plymouth (root during init)
> powertop (already requires root)
> util-linux (already required root for "setterm -msg ...")
> valgrind (agnostic: used only as a hook for debugee)
>
> Not running as root:
>
> util-linux (dmesg: what we're trying to deal with)

Thanks for the speedy analysis.

>
> So, I think this should be a safe change, outside of the educational change
> I already mentioned for dmesg itself.


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



--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 11-17-2010, 08:59 AM
David Henningsson
 
Default CONFIG_SECURITY_DMESG_RESTRICT

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.

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

--
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 11-17-2010, 07:34 PM
Kees Cook
 
Default CONFIG_SECURITY_DMESG_RESTRICT

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

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 11-17-2010, 11:26 PM
Colin Ian King
 
Default CONFIG_SECURITY_DMESG_RESTRICT

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
>



--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 11-17-2010, 11:38 PM
Kees Cook
 
Default CONFIG_SECURITY_DMESG_RESTRICT

On Thu, Nov 18, 2010 at 12:26:08AM +0000, Colin Ian King wrote:
> So are we going to change permissions on files such
> as /var/log/dmesg, /var/log/kern.log et al too?

kern.log is already correct, but we should change dmesg, yes.

--
Kees Cook
Ubuntu Security Team

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 11-18-2010, 05:05 PM
Jeremy Foshee
 
Default CONFIG_SECURITY_DMESG_RESTRICT

On Wed, Nov 17, 2010 at 04:38:13PM -0800, Kees Cook wrote:
> On Thu, Nov 18, 2010 at 12:26:08AM +0000, Colin Ian King wrote:
> > So are we going to change permissions on files such
> > as /var/log/dmesg, /var/log/kern.log et al too?
>
> kern.log is already correct, but we should change dmesg, yes.
>
I wonder what implication this has on our bug reports that will always
contain this information now.

Will this create a need to not get dmesg due to attack concerns? We
already have procedures in place for removing or scrubbing sensitive
information as a part of the general triage information. Will removing
or scrubbing this file need to become part of that?

~JFo
> --
> Kees Cook
> Ubuntu Security Team
>
> --
> kernel-team mailing list
> kernel-team@lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/kernel-team
>

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 

Thread Tools




All times are GMT. The time now is 07:15 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org