Re: Enabling the kernel's DMESG_RESTRICT feature
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 (m...@ubuntu.com): 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 ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Enabling the kernel's DMESG_RESTRICT feature
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 (m...@ubuntu.com): 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 ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Enabling the kernel's DMESG_RESTRICT feature
On Thu, Jun 2, 2011 at 8:14 AM, Matt Zimmerman m...@ubuntu.com 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 ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Enabling the kernel's DMESG_RESTRICT feature
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 sbeat...@ubuntu.com http://NxNW.org/~steve/ signature.asc Description: Digital signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Enabling the kernel's DMESG_RESTRICT feature
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 ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Enabling the kernel's DMESG_RESTRICT feature
On Fri, May 27, 2011 at 7:44 AM, Kees Cook k...@ubuntu.com 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
#include unistd.h
#include stdio.h
int main ( int argc, char** argv )
{
int last_char = 0;
int this_char;
int in_address = 0;
FILE *f = fopen ( /var/log/dmesg, r );
if (setuid(getuid())) { /* drop root privileges */
puts(Cannot drop root privileges\n);
return 1;
}
while ( (this_char = fgetc(f)) != EOF) {
if (this_char 33 || this_char == ']' || this_char == '-') {
// A space, newline or special char
in_address = 0;
}
if (in_address) {
putchar('?');
} else {
putchar((char)this_char);
}
if (last_char=='0' this_char=='x') {
in_address=1;
}
last_char = this_char;
}
return (0);
}
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Enabling the kernel's DMESG_RESTRICT feature
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 ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Enabling the kernel's DMESG_RESTRICT feature
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 ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Enabling the kernel's DMESG_RESTRICT feature
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 ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Enabling the kernel's DMESG_RESTRICT feature
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-netdevm=128915072325450w=2 -- Kees Cook Ubuntu Security Team -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Enabling the kernel's DMESG_RESTRICT feature
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 0xc100): $ dmesg | grep -m1 text [0.00] .text : 0xc100 - 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 ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Enabling the kernel's DMESG_RESTRICT feature
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 adm53466 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 ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Enabling the kernel's DMESG_RESTRICT feature
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 ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Enabling the kernel's DMESG_RESTRICT feature
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.00] .text : 0xc100 - 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 ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Enabling the kernel's DMESG_RESTRICT feature
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 ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Enabling the kernel's DMESG_RESTRICT feature
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 ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Enabling the kernel's DMESG_RESTRICT feature
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 ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Enabling the kernel's DMESG_RESTRICT feature
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 ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Enabling the kernel's DMESG_RESTRICT feature
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 ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Enabling the kernel's DMESG_RESTRICT feature
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 0xc100): $ dmesg | grep -m1 text [0.00] .text : 0xc100 - 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 ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Enabling the kernel's DMESG_RESTRICT feature
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 ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Enabling the kernel's DMESG_RESTRICT feature
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 ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Enabling the kernel's DMESG_RESTRICT feature
Hey Kees, Kees Cook [2011-05-24 11:46 -0700]: $ dmesg | grep -m1 text [0.00] .text : 0xc100 - 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 ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
