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/ slanga...@ubuntu.com vor...@debian.org
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
