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
|

Enabling the kernel's DMESG_RESTRICT feature

Kees Cook-5
Hello!

In Oneiric, I'd like to change the default availability of yet another
long-standing system debugging feature: dmesg.

Since Linux 2.6.37, CONFIG_DMESG_RESTRICT (/proc/sys/kernel/dmesg_restrict)
has existed[1], but the default in Ubuntu has been to leave "dmesg" available
to unprivileged users (i.e. lacking the CAP_SYSLOG capability, changed
in 2.6.38[2]). I brought this up[3] in November, but ultimately decided to
wait until we had more important reasons to enable it by default.

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.

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)


Now, making "dmesg" a privileged command will require extensive changes
to documentation, debug-info-gather tools (e.g. users of "dmesg"
like Apport), etc. The syslog daemon already has the needed privileges
since it does more than just read the klog buffer (see [3] for a full
list of klogctl() users). As with last year's ptrace changes[5],
I plan to patch the userspace tools (i.e. "dmesg") themselves to
produce a useful error message instead of what it current reports when
/proc/sys/kernel/dmesg_restrict is set to "1":

$ dmesg
klogctl: Operation not permitted

I think something like this will be used:

$ dmesg
klogctl: Operation not permitted
The kernel syslog is only available to privileged users. For more details,
see /etc/sysctl.d/10-dmesg.conf

And then there will be extended information in that file, etc.


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

Thoughts, flames, etc?

-Kees

[1] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=eaf06b241b091357e72b76863ba16e89610d31bd

[2] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=38ef4c2e437d11b5922723504b62824e96761459

[3] https://lists.ubuntu.com/archives/kernel-team/2010-November/013499.html

[4] https://lkml.org/lkml/2011/5/22/99

[5] https://lists.ubuntu.com/archives/ubuntu-devel/2010-May/030797.html

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

Clint Byrum-4
Excerpts from Kees Cook's message of Tue May 24 11:46:48 -0700 2011:

> 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...
>
> Thoughts, flames, etc?

+1

I've always been a bit surprised at how much I can see in /var/log when
logged into a brand new box as the initial admin user. I think users are
accustomed to sudo when debugging issues, and I'm comfortable with saying
that reading /var/log/* is just one more thing you need to use sudo for.

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

Bryce Harrington-5
In reply to this post by Kees Cook-5
On Tue, May 24, 2011 at 11:46:48AM -0700, Kees Cook wrote:
> Hello!
>
> In Oneiric, I'd like to change the default availability of yet another
> long-standing system debugging feature: dmesg.
>
> Thoughts, flames, etc?

See https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/716595 for some
sudo caching problems apport has had to work around which might pose
some complications here as well.

Can you outline your plans for updating apport in conjunction with this
change?

Bryce

--
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 Tue, May 24, 2011 at 03:59:53PM -0700, Bryce Harrington wrote:

> On Tue, May 24, 2011 at 11:46:48AM -0700, Kees Cook wrote:
> > Hello!
> >
> > In Oneiric, I'd like to change the default availability of yet another
> > long-standing system debugging feature: dmesg.
> >
> > Thoughts, flames, etc?
>
> See https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/716595 for some
> sudo caching problems apport has had to work around which might pose
> some complications here as well.

Yeah, that bug is pretty ugly. :)

> Can you outline your plans for updating apport in conjunction with this
> change?

Well, it needs to be larger than just apport. A lot of things call dmesg,
and I can't fix them all, but getting people educated about what has
changed is the first step.

As for apport itself, I do not have an immediate solution. hookutils.py's
attachmesg() will need privs, and that's used all over the place
(attach_alsa(), attach_hardware()):

$ find -P /usr/share/apport -type f | xargs egrep -H 'attach_(hardware|alsa|dmesg)' | cut -d: -f1 | sort -u | wc -l
33

I'm open to suggestions.

-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

Brad Figg-2
On 05/24/2011 04:49 PM, Kees Cook wrote:

> On Tue, May 24, 2011 at 03:59:53PM -0700, Bryce Harrington wrote:
>> On Tue, May 24, 2011 at 11:46:48AM -0700, Kees Cook wrote:
>>> Hello!
>>>
>>> In Oneiric, I'd like to change the default availability of yet another
>>> long-standing system debugging feature: dmesg.
>>>
>>> Thoughts, flames, etc?
>>
>> See https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/716595 for some
>> sudo caching problems apport has had to work around which might pose
>> some complications here as well.
>
> Yeah, that bug is pretty ugly. :)
>
>> Can you outline your plans for updating apport in conjunction with this
>> change?
>
> Well, it needs to be larger than just apport. A lot of things call dmesg,
> and I can't fix them all, but getting people educated about what has
> changed is the first step.
>
> As for apport itself, I do not have an immediate solution. hookutils.py's
> attachmesg() will need privs, and that's used all over the place
> (attach_alsa(), attach_hardware()):
>
> $ find -P /usr/share/apport -type f | xargs egrep -H 'attach_(hardware|alsa|dmesg)' | cut -d: -f1 | sort -u | wc -l
> 33
>
> I'm open to suggestions.
>
> -Kees
>

Just FYI, the kernel hooks already ask for permissions to get the
ACPI tables.

Brad
--
Brad Figg [hidden email] http://www.canonical.com

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

Martin Pitt-4
In reply to this post by Kees Cook-5
Hey Kees,

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

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?

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
Reply | Threaded
Open this post in threaded view
|

Re: Enabling the kernel's DMESG_RESTRICT feature

Stefan Bader-2
On 25.05.2011 06:41, Martin Pitt wrote:

> Hey Kees,
>
> 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
> 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.
>
Though IMO that is a decision made by them then. And changing that might not be
seen as "fixing" something.

> 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?
>
I do not really like that idea that much. Probably because of looking at it from
a practical debugging side. What gets into dmesg gets onto the console and if
something goes wrong early enough that is the only source of information. Also
when looking at bare dumps, its simple to find that buffer.

Stefan

> Martin
>


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

Scott Kitterman-3
In reply to this post by Clint Byrum-4
On Tuesday, May 24, 2011 06:00:17 PM Clint Byrum wrote:

> Excerpts from Kees Cook's message of Tue May 24 11:46:48 -0700 2011:
> > 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...
> >
> > Thoughts, flames, etc?
>
> +1
>
> I've always been a bit surprised at how much I can see in /var/log when
> logged into a brand new box as the initial admin user. I think users are
> accustomed to sudo when debugging issues, and I'm comfortable with saying
> that reading /var/log/* is just one more thing you need to use sudo for.

This doesn't match how I think of it, but I may be unusual (in this regard -
otherwise I think that's already well established).  I have tended to view
sudo/root as "ooh, be careful not to break the system" and "understand the
system" as something I should do as a normal user (with limited exceptions).

Currently on the 11.04 system I'm typing this on, I have:

-rw-r----- 1 root   adm    53466 2011-05-24 13:19 dmesg

/var/log has a mix of files owned by group root and group adm.  Instead of
removing normal user access to all the files in /var/log, couldn't we just
change the group of dmesg* to root?

I don't know about other GUI tools, but Kubuntu's userconfig gives a checkbox
to "Access system logs" that adds the user to adm.  If we're fundamentally
changing how system logs are accessed we'll need to change that.  Other GUI
user configuration tools should also be checked for this (and appropriate work
items added to the spec.

Scott K

--
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 Wed, May 25, 2011 at 08:07:14AM -0400, Scott Kitterman wrote:

> On Tuesday, May 24, 2011 06:00:17 PM Clint Byrum wrote:
> > Excerpts from Kees Cook's message of Tue May 24 11:46:48 -0700 2011:
> > > 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...
> > >
> > > Thoughts, flames, etc?
> >
> > +1
> >
> > I've always been a bit surprised at how much I can see in /var/log when
> > logged into a brand new box as the initial admin user. I think users are
> > accustomed to sudo when debugging issues, and I'm comfortable with saying
> > that reading /var/log/* is just one more thing you need to use sudo for.

Clint, what do you think of the proposal below? It's a less dramatic
change, which might be more well received ultimately.

> This doesn't match how I think of it, but I may be unusual (in this regard -
> otherwise I think that's already well established).  I have tended to view
> sudo/root as "ooh, be careful not to break the system" and "understand the
> system" as something I should do as a normal user (with limited exceptions).
>
> Currently on the 11.04 system I'm typing this on, I have:
>
> -rw-r----- 1 root   adm    53466 2011-05-24 13:19 dmesg
>
> /var/log has a mix of files owned by group root and group adm.  Instead of
> removing normal user access to all the files in /var/log, couldn't we just
> change the group of dmesg* to root?
>
> I don't know about other GUI tools, but Kubuntu's userconfig gives a checkbox
> to "Access system logs" that adds the user to adm.  If we're fundamentally
> changing how system logs are accessed we'll need to change that.  Other GUI
> user configuration tools should also be checked for this (and appropriate work
> items added to the spec.

Yeah, same for Gnome (adm group checkbox). Just changing the specific log
file permissions does seem to be the "least surprising" method to deal with
this. I will go that route, thanks.

-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-8
In reply to this post by Brad Figg-2
Hi Brad,

On Tue, May 24, 2011 at 05:53:22PM -0700, Brad Figg wrote:

> On 05/24/2011 04:49 PM, Kees Cook wrote:
> >On Tue, May 24, 2011 at 03:59:53PM -0700, Bryce Harrington wrote:
> >>On Tue, May 24, 2011 at 11:46:48AM -0700, Kees Cook wrote:
> >>>Hello!
> >>>
> >>>In Oneiric, I'd like to change the default availability of yet another
> >>>long-standing system debugging feature: dmesg.
> >>>
> >>>Thoughts, flames, etc?
> >>
> >>See https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/716595 for some
> >>sudo caching problems apport has had to work around which might pose
> >>some complications here as well.
> >
> >Yeah, that bug is pretty ugly. :)
> >
> >>Can you outline your plans for updating apport in conjunction with this
> >>change?
> >
> >Well, it needs to be larger than just apport. A lot of things call dmesg,
> >and I can't fix them all, but getting people educated about what has
> >changed is the first step.
> >
> >As for apport itself, I do not have an immediate solution. hookutils.py's
> >attachmesg() will need privs, and that's used all over the place
> >(attach_alsa(), attach_hardware()):
> >
> >$ find -P /usr/share/apport -type f | xargs egrep -H 'attach_(hardware|alsa|dmesg)' | cut -d: -f1 | sort -u | wc -l
> >33
> >
> >I'm open to suggestions.
> >
> >-Kees
> >
>
> Just FYI, the kernel hooks already ask for permissions to get the
> ACPI tables.

Yeah, the problem is that it's not a one-time question (see the bug above),
so that each time we need privileges to gather data, apport will prompt for
the sudo password _again_. :(

Martin, do you have any thoughts on ways to deal with this? You did a lot
of digging in that bug, and nothing really presented itself as a clean
solution...

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

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

Martin Pitt-4
In reply to this post by Kees Cook-8
Hello Kees, all,

Kees Cook [2011-05-25 10:03 -0700]:
> Yeah, the problem is that it's not a one-time question (see the bug above),
> so that each time we need privileges to gather data, apport will prompt for
> the sudo password _again_. :(

One word: attach_root_command_outputs() :)

Hooks can and should  use this apport.hookutils function if they have
several log files to attach.

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
Reply | Threaded
Open this post in threaded view
|

Re: Enabling the kernel's DMESG_RESTRICT feature

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

> Since Linux 2.6.37, CONFIG_DMESG_RESTRICT (/proc/sys/kernel/dmesg_restrict)
> has existed[1], but the default in Ubuntu has been to leave "dmesg" available
> to unprivileged users (i.e. lacking the CAP_SYSLOG capability, changed
> in 2.6.38[2]). I brought this up[3] in November, but ultimately decided to
> wait until we had more important reasons to enable it by default.

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

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.

> 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?

> 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!

I'd much rather we find a way to fix it so the information *logged* to these
files isn't privileged to the point that it can't be exposed to admins,
instead of gutting admins' ability to make use of these crucial logs.

--
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
[hidden email]                                     [hidden email]

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

signature.asc (845 bytes) Download Attachment
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 08:27:01PM +0200, Martin Pitt wrote:

> Hello Kees, all,
>
> Kees Cook [2011-05-25 10:03 -0700]:
> > Yeah, the problem is that it's not a one-time question (see the bug above),
> > so that each time we need privileges to gather data, apport will prompt for
> > the sudo password _again_. :(
>
> One word: attach_root_command_outputs() :)
>
> Hooks can and should  use this apport.hookutils function if they have
> several log files to attach.

But the existing code for attach_dmesg() doesn't really fold into that very
well since it's reading the old /var/log/dmesg file, then running "dmesg"
itself, etc.

--
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:
> I'd much rather we find a way to fix it so the information *logged* to these
> files isn't privileged to the point that it can't be exposed to admins,
> instead of gutting admins' ability to make use of these crucial logs.

Currently, the upstream kernel folks have rejected filtering printk.
However, there has been some noise recently about making a distinction
between the "actual" address and the "unrandomized" address. (As in, printk
would be forced to use a new %p modifier for all kernel addresses, and that
modifier would report the "unrandomized" address by default, keeping the
actual address secret even from dmesg.

We'll see how this progresses...

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

Bryce Harrington-5
In reply to this post by Kees Cook-5
On Wed, May 25, 2011 at 12:01:42PM -0700, Kees Cook wrote:

> On Wed, May 25, 2011 at 08:27:01PM +0200, Martin Pitt wrote:
> > Hello Kees, all,
> >
> > Kees Cook [2011-05-25 10:03 -0700]:
> > > Yeah, the problem is that it's not a one-time question (see the bug above),
> > > so that each time we need privileges to gather data, apport will prompt for
> > > the sudo password _again_. :(
> >
> > One word: attach_root_command_outputs() :)
> >
> > Hooks can and should  use this apport.hookutils function if they have
> > several log files to attach.
>
> But the existing code for attach_dmesg() doesn't really fold into that very
> well since it's reading the old /var/log/dmesg file, then running "dmesg"
> itself, etc.

I guess the implication here is that if a script is already using
attach_root_command_outputs() then if it wants dmesg it should include
that file in that call, and forswear use of attach_dmesg().

Bryce

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

Martin Pitt-4
In reply to this post by Kees Cook-5
Kees Cook [2011-05-25 12:01 -0700]:
> On Wed, May 25, 2011 at 08:27:01PM +0200, Martin Pitt wrote:
> > One word: attach_root_command_outputs() :)
> >
> > Hooks can and should  use this apport.hookutils function if they have
> > several log files to attach.
>
> But the existing code for attach_dmesg() doesn't really fold into that very
> well since it's reading the old /var/log/dmesg file, then running "dmesg"
> itself, etc.

You can actually run attach_root_command_outputs() several times in a
row, and the subsequent times it won't ask for another password, but
retain the sudo ticket. That just doesn't work for
root_command_output() as that also captures stderr (and then sudo
doesn't have any remaining tty any more to get the ticket from).

So if needed, you can implement attach_dmesg() with
attach_root_command_outputs().

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

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
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 Kees Cook-5
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?

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
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 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?

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

Clint Byrum-4
In reply to this post by Kees Cook-5
Excerpts from Kees Cook's message of Wed May 25 10:01:12 -0700 2011:

> On Wed, May 25, 2011 at 08:07:14AM -0400, Scott Kitterman wrote:
> > On Tuesday, May 24, 2011 06:00:17 PM Clint Byrum wrote:
> > > Excerpts from Kees Cook's message of Tue May 24 11:46:48 -0700 2011:
> > > > 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...
> > > >
> > > > Thoughts, flames, etc?
> > >
> > > +1
> > >
> > > I've always been a bit surprised at how much I can see in /var/log when
> > > logged into a brand new box as the initial admin user. I think users are
> > > accustomed to sudo when debugging issues, and I'm comfortable with saying
> > > that reading /var/log/* is just one more thing you need to use sudo for.
>
> Clint, what do you think of the proposal below? It's a less dramatic
> change, which might be more well received ultimately.

+1 for a less surprising and still quite effective way of achieving the goal.

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