Date: Thu, 27 Oct 2011 23:38:47 -0400 (EDT) From: "Steven M. Christey" <coley@...-smtp.mitre.org> To: oss-security@...ts.openwall.com, kseifried@...hat.com cc: cve-assign@...re.org Subject: Re: CVE Request -- kernel: sysctl: restrict write access to dmesg_restrict All, There was some discussion in January 2011 regarding CAP_SYS_ADMIN and how security boundaries are defined: http://openwall.com/lists/oss-security/2011/01/07/1 By this kind of logic, even though it's "silly" and a very low risk because it requires such high privileges to exploit, the ability for an attacker to bypass CAP_SYS_ADMIN by modifying dmesg_restrict so that the attacker can read the kernel ring buffer, seems to bypass an intended security policy, at least as the policy as it's currently implemented. There are a couple other statements worth considering: 1) Vasiliy (with Dan's agreement) saying that "LXC security boundaries in the mainline kernel are not well defined at this point." http://openwall.com/lists/oss-security/2011/10/26/11 2) Vasiliy's statement that "Procfs is not ready for containers yet." I'm not sure what this means, exactly - is procfs code being modified to support containers, and development isn't complete? 3) Vasiliy's statement that an attacker can "use other sysctls for more harmful things." If a user already has legitimate, "acceptable" privileges to perform an action that is equivalent to CAP_SYS_ADMIN/dmesg_restrict, then the bypass does not cross security boundaries. If we can get agreement that there isn't a well-defined security policy yet (at least by the kernel people who are on oss-security), and if there's agreement that procfs isn't being advertised to conform to any such policy in the first place, then there could be some collective community decision to decide that these kinds of issues don't (yet) represent any violation of an explicit security policy. This could then shape future decisions for whether we continue to assign CVEs for these kinds of issues, at least until some more explicit policy is defined. So, I'll repeat my subtle request in January for someone to try and define what the acceptable security boundaries are at this stage, and then it should make it easier to interpret what needs a CVE (or not). It sounds like this could have some benefits beyond CVE. Looks like Brad Spengler's blog post at http://forums.grsecurity.net/viewtopic.php?f=7&t=2522 is a great start; based on my (limited) understanding, this suggests that CAP_SYS_ADMIN can legitimately transition to full root. - Steve
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.