Enabled hardening of dmesg in grsecurity and default linux kernel. So only root should be able to do dmesg. After installing the kernel a normal user can still perform dmesg. Reproducible: Always Steps to Reproduce: 1.Compile kernel with following flags $ zgrep DMESG /proc/config.gz CONFIG_GRKERNSEC_DMESG=y CONFIG_SECURITY_DMESG_RESTRICT=y 2. Enable hardening of dmesg in /etc/sysctl.conf and reboot: $ sudo sysctl -a | grep dmesg kernel.dmesg_restrict = 1 kernel.grsecurity.dmesg = 1 3. perform dmesg as non root user: $ dmesg | head -n2 [ 0.000000] Initializing cgroup subsys cpuset [ 0.000000] Initializing cgroup subsys cpu Actual Results: Non root user can perform dmesg just as usual. Expected Results: Permission denied when dmesg is performed as non root user.
I just tried this on 3.8.7 which I just added to the tree, and I'm getting the expected failure. I wonder if it was specific to 3.7.5-r1 dmesg: read kernel buffer failed: Operation not permitted
It's also fixed in the just-gone-stable hardened-3.8.3.
(In reply to comment #2) > It's also fixed in the just-gone-stable hardened-3.8.3. Cool, will try that later. Curious though, how do you test these kernels before marking them stable? Is there a basic test suite of some sort?
(In reply to comment #3) > (In reply to comment #2) > > It's also fixed in the just-gone-stable hardened-3.8.3. > > Cool, will try that later. > > Curious though, how do you test these kernels before marking them stable? > Is there a basic test suite of some sort? Every kernel that goes on the tree is tested with a basic config file on a vm, both x86 and amd64. If it passes then it is placed on the tree where others will have to test and report --- there is no other way with the kernel since I do not have all the possible hardware it will be run on. Reports are then sifted, first whether or not they are hardened specific or generic kernel problems. If they are hardened, then I either fix or pass upstream. Almost always the grsec/pax team has already fixed it. Once a kernel has been on the tree long enough and it has only minimal bugs, I stabilize.
I have the same problem with gentoo-sources-3.8.7 and 3.8.8 (not hardened). Could be more ancient, I haven't made yet the effort to bissect. root# uname -a Linux hallucigenia 3.8.8-gentoo #1 SMP Thu Apr 18 09:04:17 WEST 2013 x86_64 Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz GenuineIntel GNU/Linux root# sysctl -a|grep -i "dmesg" kernel.dmesg_restrict = 1 root# jerome/ zgrep -i "dmesg" /proc/config.gz CONFIG_SECURITY_DMESG_RESTRICT=y
Problem present also in gentoo-sources-3.7.10 and CONFIG_SECURITY_DMESG_RESTRICT=y.
(In reply to comment #6) > Problem present also in gentoo-sources-3.7.10 and > CONFIG_SECURITY_DMESG_RESTRICT=y. To be clear, its probably not even gentoo sources but vanilla. Just so we know where to aim the blame.
FYI: https://bugzilla.redhat.com/show_bug.cgi?id=903192 As far as I know a recent change in util-linux introduced this.
Does anyone know if this has been fixed in vanilla 3.8.*
Looking at commit messages containing dmesg, there are relevant: 04 Apr 2012: 620f6e8 sysctl: fix write access to dmesg_restrict/kptr_restrict 07 Mar 2012: dd09979 staging: android: ram_console: honor dmesg_restrict 23 Mar 2011: bfdc0b4 sysctl: restrict write access to dmesg_restrict 08 Dec 2010: 38ef4c2 syslog: check cap_syslog when dmesg_restrict Looking for cap_syslog I see some talk regarding a cap_sys_admin override: commit f2c0d0266cc5eb36a4aa44944b4096ec121490aa Author: Jonathan Nieder <jrnieder@gmail.com> Date: Mon Aug 8 06:22:43 2011 +0200 cap_syslog: don't use WARN_ONCE for CAP_SYS_ADMIN deprecation warning syslog-ng versions before 3.3.0beta1 (2011-05-12) assume that CAP_SYS_ADMIN is sufficient to access syslog, so ever since CAP_SYSLOG was introduced (2010-11-25) they have triggered a warning. Commit ee24aebffb75 ("cap_syslog: accept CAP_SYS_ADMIN for now") improved matters a little by making syslog-ng work again, just keeping the WARN_ONCE(). But still, this is a warning that writes a stack trace we don't care about to syslog, sets a taint flag, and alarms sysadmins when nothing worse has happened than use of an old userspace with a recent kernel. Convert the WARN_ONCE to a printk_once to avoid that while continuing to give userspace developers a hint that this is an unwanted backward-compatibility feature and won't be around forever. ... commit ee24aebffb75a7f940cf52c8cf6910947b3130c0 Author: Linus Torvalds <torvalds@linux-foundation.org> Date: Thu Feb 10 17:53:55 2011 -0800 cap_syslog: accept CAP_SYS_ADMIN for now In commit ce6ada35bdf7 ("security: Define CAP_SYSLOG") Serge Hallyn introduced CAP_SYSLOG, but broke backwards compatibility by no longer accepting CAP_SYS_ADMIN as an override (it would cause a warning and then reject the operation). Re-instate CAP_SYS_ADMIN - but keeping the warning - as an acceptable capability until any legacy applications have been updated. There are apparently applications out there that drop all capabilities except for CAP_SYS_ADMIN in order to access the syslog. (This is a re-implementation of a patch by Serge, cleaning the logic up and making the code more readable) ... I don't think they would keep dmesg security this broken for so long. Maybe this override is in place in this case?
Testing out vanilla-3.9.3 today. The problem is still there. CONFIG_SECURITY_DMESG_RESTRICT=y, but non-root can view dmesg.
I added a patch from linux-next into gentoo-sources-3.9 which addresses this issue. This will be in the next release of 3.9.X $ dmesg dmesg: read kernel buffer failed: Operation not permitted $ grep DMESG /usr/src/linux/.config CONFIG_SECURITY_DMESG_RESTRICT=y http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/patch/?id=d32bf5fd3321a5b909482726dac34594dc3af758
(In reply to Mike Pagano from comment #12) > I added a patch from linux-next into gentoo-sources-3.9 which addresses this > issue. This will be in the next release of 3.9.X This is in the kernel itself since 3.9.7 and therefore it has been removed. Can someone that has experienced this problem confirm that it works in 3.9.7?
Can confirm with vanilla-sources-3.9.7. CONFIG_SECURITY_DMESG_RESTRICT=y and non-root cannot view dmesg.
