Home page logo
/

oss-sec logo oss-sec mailing list archives

Re: CVE Request -- kernel: sysctl: restrict write access to dmesg_restrict
From: "Steven M. Christey" <coley () rcf-smtp mitre org>
Date: Thu, 27 Oct 2011 23:38:47 -0400 (EDT)


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


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
AlienVault