Date: Wed, 26 Oct 2011 20:14:08 +0400 From: Solar Designer <solar@...nwall.com> To: oss-security@...ts.openwall.com Subject: Re: CVE Request -- kernel: sysctl: restrict write access to dmesg_restrict On Wed, Oct 26, 2011 at 05:16:12PM +0200, Petr Matousek wrote: > When dmesg_restrict is set to 1 CAP_SYS_ADMIN is needed to read the > kernel ring buffer. But a root user without CAP_SYS_ADMIN is able > to reset dmesg_restrict to 0. FWIW, here's how this is implemented in OpenVZ, at least in RHEL5 branch kernels: suse114:/ # id uid=0(root) gid=0(root) groups=0(root) suse114:/ # sysctl -a|fgrep dmesg kernel.dmesg_restrict = 1 suse114:/ # sysctl -w kernel.dmesg_restrict=0 error: "Operation not permitted" setting key "kernel.dmesg_restrict" suse114:/ # uname -mrs Linux 2.6.18-274.3.1.el5.028stab094.3.owl1 x86_64 suse114:/ # dmesg klogctl: Operation not permitted This is OpenSUSE 11.4 (arbitrary, whatever I happened to have as a result of some other testing) inside an OpenVZ container on Owl. ;-) I was actually thinking of making dmesg_restrict tri-state in OpenVZ, to have a setting that would allow dmesg to work in containers but not on host. With OpenVZ, containers have their own dmesg buffers anyway, with very little info getting in there (e.g., output from virtualized iptables logging goes in there, but I've never seen any kernel pointer exposed in an in-container dmesg). Fully disabling dmesg in containers just because we want it disabled for non-root on host seems overkill for some uses, but that's what is currently implemented when a host admin sets dmesg_restrict to 1. There's room for improvement here, from a usability standpoint. As to security, this shows that OpenVZ is mature and LXC is not. ;-) Alexander
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.