Enabling the kernel's DMESG_RESTRICT feature

classic Classic list List threaded Threaded
35 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Enabling the kernel's DMESG_RESTRICT feature

Kees Cook-5
On Wed, May 25, 2011 at 09:36:16PM +0200, Martin Pitt wrote:
> So if needed, you can implement attach_dmesg() with
> attach_root_command_outputs().

Ah, perfect. That'll be the way to go, then.

> But aside from that I do agree with Steve that it both seems a lot
> safer as well as more convenient and less intrusive to just filter out
> the address from the printk in the first place, instead of disallowing
> non-admins to see some useful debugging (like errors on removable disk
> drives, what the heck is currently wrong with their wifi, etc.)

This just isn't going to happen, unfortunately. The number of leaks is
giant, and upstream is completely unwilling to filter printk() so far.

I wanted to get this turned on now because it will be needed once we have
kernel base address randomization, and if that happens for the LTS, I
didn't want to have to make the dmesg privilege transition also in LTS.

-Kees

--
Kees Cook
Ubuntu Security Team

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: Enabling the kernel's DMESG_RESTRICT feature

Kees Cook-5
In reply to this post by Martin Pitt-4
On Wed, May 25, 2011 at 09:37:47PM +0200, Martin Pitt wrote:
> Kees Cook [2011-05-25 12:05 -0700]:
> > Currently, the upstream kernel folks have rejected filtering printk.
>
> That's not actually what I meant. Don't filter the outputs of printk()
> with some regexps. I meant "just kill the printk() call that prints
> the address". Why would you even need to printk() it if the very thing
> it prints out is not meant to be seen in logs?

Right. This is precisely what upstream has refused[1] to do.

The problem is that dmesg is just a log. The contents can't be adjusted
based on who is viewing it like (like has been done for the %pK sprintf
uses in /proc, /sys, etc). Things like Oops reports will go to dmesg, which
are utterly useless without all their addresses intact, etc.

The only way to close this entire area of leaks is to make dmesg a
privileged resource, and that is possible using the dmesg_restrict stuff
(created for this very purpose).

-Kees

[1] http://marc.info/?l=linux-netdev&m=128915072325450&w=2

--
Kees Cook
Ubuntu Security Team

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: Enabling the kernel's DMESG_RESTRICT feature

Kees Cook-5
In reply to this post by Matt Zimmerman-2
On Thu, May 26, 2011 at 04:41:04PM +0100, Matt Zimmerman wrote:

> On Tue, May 24, 2011 at 11:46:48AM -0700, Kees Cook wrote:
> > As we have continued to close kernel address leaks, the kernel syslog
> > (dmesg) remains one of the last large places where information is being
> > reported. As such, I want to close this off from regular users so that
> > local kernel exploits continue to have an even harder time getting a
> > foot-hold on vulnerabilities. And, as before, this is a tunable that you
> > can change in /etc/sysctl.d/ if you do development work, like getting
> > owned, etc. For the average user, this information is not needed.
>
> What are the ways in which kernel addresses are leaked through dmesg?  Can
> you provide some examples?  Is it not feasible to avoid leaking addresses,
> while still passing on all of the useful data in dmesg to users?

Many net reports include specific heap allocation structures, Oops reports,
boot-up reports, there are hundreds of places, and they're reported to
dmesg for the specific purpose of being able to examine them later.
Eliminating them from dmesg would be much much worse than making access to
dmesg privileged. It goes from literally being unable to debug a problem to
just needing to be root to do it.

-Kees

--
Kees Cook
Ubuntu Security Team

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: Enabling the kernel's DMESG_RESTRICT feature

Kees Cook-5
In reply to this post by Steve Langasek-6
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

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: Enabling the kernel's DMESG_RESTRICT feature

John McCabe-Dansted
In reply to this post by Kees Cook-5
On Fri, May 27, 2011 at 7:44 AM, Kees Cook <[hidden email]> wrote:
> The problem is that dmesg is just a log. The contents can't be adjusted
> based on who is viewing it like (like has been done for the %pK sprintf
> uses in /proc, /sys, etc). Things like Oops reports will go to dmesg, which
> are utterly useless without all their addresses intact, etc.

One could also provide an suid utility that stripped out everything
that looks like an address.

For fun, I attach such a utility, though I am not convinced this is
the best approach. It
 1) opens /var/log/dmesg
 2) drops root privileges
 3) filters out everything starting with '0x'

It strips out lots of things that aren't addresses, but It looks like
what it leaves could still be useful for many purposes. It may well
still leave some sensitive information unprotected, so I wouldn't use
it when it is not needed, particularly as it may cause confusion if
users mistake it for the real dmesg.

--
John C. McCabe-Dansted

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

udmesg.c (940 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Enabling the kernel's DMESG_RESTRICT feature

Matt Zimmerman-2
In reply to this post by Kees Cook-5
On Thu, May 26, 2011 at 04:55:59PM -0700, Kees Cook wrote:
> 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.

It seems we are forced into this dichotomy because there is only one log,
which is mixing different types of information.  Has anyone proposed
separating kernel debugging information from simple status logging, and
allowing the remainder to remain accessible to users?

--
 - mdz

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: Enabling the kernel's DMESG_RESTRICT feature

Kees Cook-5
On Fri, May 27, 2011 at 04:29:33PM +0100, Matt Zimmerman wrote:

> On Thu, May 26, 2011 at 04:55:59PM -0700, Kees Cook wrote:
> > 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.
>
> It seems we are forced into this dichotomy because there is only one log,
> which is mixing different types of information.  Has anyone proposed
> separating kernel debugging information from simple status logging, and
> allowing the remainder to remain accessible to users?

I don't think this would end up being sensible either, as the task of
performing debugging may need access to both. I still don't see the problem
of debugging as root. If you're not the system owner, you're not going to
be able to _change_ the system in an effort to fix the problem you are
debugging.

--
Kees Cook
Ubuntu Security Team

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: Enabling the kernel's DMESG_RESTRICT feature

Matt Zimmerman-2
On Fri, May 27, 2011 at 10:17:59AM -0700, Kees Cook wrote:

> On Fri, May 27, 2011 at 04:29:33PM +0100, Matt Zimmerman wrote:
> > On Thu, May 26, 2011 at 04:55:59PM -0700, Kees Cook wrote:
> > > 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.
> >
> > It seems we are forced into this dichotomy because there is only one log,
> > which is mixing different types of information.  Has anyone proposed
> > separating kernel debugging information from simple status logging, and
> > allowing the remainder to remain accessible to users?
>
> I don't think this would end up being sensible either, as the task of
> performing debugging may need access to both. I still don't see the problem
> of debugging as root. If you're not the system owner, you're not going to
> be able to _change_ the system in an effort to fix the problem you are
> debugging.

Maybe I'm weird, but I use dmesg for a lot of "normal" tasks, not just
debugging problems which will require root to fix.  The most common is
probably the traditional "what device node was assigned to that device I
just plugged in?" query.  I also have a habit, surely derived from running
lots of bleeding edge code, of running dmesg from time to time just to check
if anything weird is going on.

--
 - mdz

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: Enabling the kernel's DMESG_RESTRICT feature

Serge Hallyn
Quoting Matt Zimmerman ([hidden email]):
> Maybe I'm weird, but I use dmesg for a lot of "normal" tasks, not just
> debugging problems which will require root to fix.  The most common is
> probably the traditional "what device node was assigned to that device I

Nothing at all weird about that.

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: Enabling the kernel's DMESG_RESTRICT feature

Kees Cook-8
On Thu, Jun 02, 2011 at 09:11:51AM -0500, Serge Hallyn wrote:
> Quoting Matt Zimmerman ([hidden email]):
> > Maybe I'm weird, but I use dmesg for a lot of "normal" tasks, not just
> > debugging problems which will require root to fix.  The most common is
> > probably the traditional "what device node was assigned to that device I
>
> Nothing at all weird about that.

Aren't we all supposed to use "udisks --enumerate" now? :)

--
Kees Cook
Ubuntu Security Team

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: Enabling the kernel's DMESG_RESTRICT feature

Matt Zimmerman-2
On Thu, Jun 02, 2011 at 10:16:04AM -0700, Kees Cook wrote:
> On Thu, Jun 02, 2011 at 09:11:51AM -0500, Serge Hallyn wrote:
> > Quoting Matt Zimmerman ([hidden email]):
> > > Maybe I'm weird, but I use dmesg for a lot of "normal" tasks, not just
> > > debugging problems which will require root to fix.  The most common is
> > > probably the traditional "what device node was assigned to that device I
> >
> > Nothing at all weird about that.
>
> Aren't we all supposed to use "udisks --enumerate" now? :)

I hadn't used that before.  You got my hopes up, and I thought it might turn
out to be a tool to map device nodes to meaningful descriptions of the
physical devices.  Oh well. :-)

--
 - mdz

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: Enabling the kernel's DMESG_RESTRICT feature

Kees Cook-5
On Thu, Jun 02, 2011 at 06:20:28PM +0100, Matt Zimmerman wrote:

> On Thu, Jun 02, 2011 at 10:16:04AM -0700, Kees Cook wrote:
> > On Thu, Jun 02, 2011 at 09:11:51AM -0500, Serge Hallyn wrote:
> > > Quoting Matt Zimmerman ([hidden email]):
> > > > Maybe I'm weird, but I use dmesg for a lot of "normal" tasks, not just
> > > > debugging problems which will require root to fix.  The most common is
> > > > probably the traditional "what device node was assigned to that device I
> > >
> > > Nothing at all weird about that.
> >
> > Aren't we all supposed to use "udisks --enumerate" now? :)
>
> I hadn't used that before.  You got my hopes up, and I thought it might turn
> out to be a tool to map device nodes to meaningful descriptions of the
> physical devices.  Oh well. :-)

Yeah, that's kind of my point; the information is scattered all over the
place. "udisks --dump" has just about everything, but is a bit non-trivial
to quickly visually scan, IMO.

--
Kees Cook
Ubuntu Security Team

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: Enabling the kernel's DMESG_RESTRICT feature

Dustin Kirkland-5
In reply to this post by Matt Zimmerman-2
On Thu, Jun 2, 2011 at 8:14 AM, Matt Zimmerman <[hidden email]> wrote:

> On Fri, May 27, 2011 at 10:17:59AM -0700, Kees Cook wrote:
>> On Fri, May 27, 2011 at 04:29:33PM +0100, Matt Zimmerman wrote:
>> > On Thu, May 26, 2011 at 04:55:59PM -0700, Kees Cook wrote:
>> > > 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.
>> >
>> > It seems we are forced into this dichotomy because there is only one log,
>> > which is mixing different types of information.  Has anyone proposed
>> > separating kernel debugging information from simple status logging, and
>> > allowing the remainder to remain accessible to users?
>>
>> I don't think this would end up being sensible either, as the task of
>> performing debugging may need access to both. I still don't see the problem
>> of debugging as root. If you're not the system owner, you're not going to
>> be able to _change_ the system in an effort to fix the problem you are
>> debugging.
>
> Maybe I'm weird, but I use dmesg for a lot of "normal" tasks, not just
> debugging problems which will require root to fix.  The most common is
> probably the traditional "what device node was assigned to that device I
> just plugged in?" query.  I also have a habit, surely derived from running
> lots of bleeding edge code, of running dmesg from time to time just to check
> if anything weird is going on.

Yeah, I use it to check if a hotplug usb disk showed up, and what scsi
device name it got assigned.

I also use it (indirectly) to monitor wifi messages a la the
wifi-status tool, which watches [iwconfig + ifconfig + dmesg]:
 * http://manpg.es/wifi-status

I suppose wifi-status might need to move to /usr/sbin, and require
sudo with your new changes, Kees?

--
:-Dustin

Dustin Kirkland
Ubuntu Core Developer

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: Enabling the kernel's DMESG_RESTRICT feature

Steve Beattie-3
In reply to this post by Kees Cook-5
On Thu, Jun 02, 2011 at 10:24:48AM -0700, Kees Cook wrote:

> On Thu, Jun 02, 2011 at 06:20:28PM +0100, Matt Zimmerman wrote:
> > On Thu, Jun 02, 2011 at 10:16:04AM -0700, Kees Cook wrote:
> > > Aren't we all supposed to use "udisks --enumerate" now? :)
> >
> > I hadn't used that before.  You got my hopes up, and I thought it might turn
> > out to be a tool to map device nodes to meaningful descriptions of the
> > physical devices.  Oh well. :-)
>
> Yeah, that's kind of my point; the information is scattered all over the
> place. "udisks --dump" has just about everything, but is a bit non-trivial
> to quickly visually scan, IMO.
"udisks --enumerate-device-files" is not particularly easy to visually
parse, but it's easier than "udisks --dump" and at least gives a
modicum of a clue as to what the device might actually be.

--
Steve Beattie
<[hidden email]>
http://NxNW.org/~steve/

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Enabling the kernel's DMESG_RESTRICT feature

Martin Pitt-4
In reply to this post by Matt Zimmerman-2
Matt Zimmerman [2011-06-02 13:14 +0100]:
> Maybe I'm weird, but I use dmesg for a lot of "normal" tasks, not just
> debugging problems which will require root to fix.

I also use it to check if there are any disk read/write errors when my
external USB hard disks act strange or slow again. Surely not the best
way to present these problems, I know, but the only one which is both
quick to do and readily available in every environment.

Martin

--
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
12