[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
