Re: CVE Request -- kernel: sysctl: restrict write access to dmesg_restrict

["Steven M. Christey" <coley () rcf-smtp mitre org>]

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