oss-security - Re: CVE Request -- kernel: sysctl: restrict write access to dmesg

Follow @Openwall on Twitter for new release announcements and other news

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Pine.GSO.4.64.1110272304280.21599@faron.mitre.org>
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

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.