[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <Pine.GSO.4.64.1101062115160.25420@faron.mitre.org>
Date: Thu, 6 Jan 2011 21:26:26 -0500 (EST)
From: "Steven M. Christey" <coley@...-smtp.mitre.org>
To: oss-security@...ts.openwall.com
Subject: Re: CVE-NONE kernel: PHONET signedness issue
On Thu, 6 Jan 2011, Michael Gilbert wrote:
> On Thu, 06 Jan 2011 13:20:49 +0800, Eugene Teo wrote:
>> re: http://seclists.org/fulldisclosure/2011/Jan/39
>>
>> Just in case someone tries to request a CVE name for this, I'm not
>> requesting for one because if you need CAP_SYS_ADMIN capability to
>> exploit this, you are already privileged.
>
> Right, but CAP_SYS_ADMIN != root, or at least it isn't meant to be. I
> mean if CAP_SYS_ADMIN == root, then one or the other doesn't need to
> exist. There is an exposure here, and for that it deserves a CVE
> identifier (of course in my opinion). See Brad Spengler's recent
> write-up [0]. There should be some effort toward making those 21 root
> equivalent capabilities discussed there non-equivalent.
Unless/until there's some formal/semi-formal statement that "CAP_SYS_ADMIN
is equivalent to root in all cases," then these kinds of
privileged-to-privileged issues are within the scope of CVE since they
violate the security model; now, they might receive very low risk scores
because the attacker is already privileged, and I could see how vendors
might reasonably avoid publishing advisories for them, but that doesn't
mean there shouldn't be a CVE assigned to it. Personally I agree with
Michael that if two cap's/privileges have both "A implies B" and "B
implies A," then one of them doesn't need to exist, but that's irrelevant.
It would be interesting (though I suspect controversial) for someone in
the Linux kernel world to take a stab at more closely defining/defining a
"security policy" regarding capability-to-capability transitions. (Or
could someone point me to one?) As a Linux outsider, I like seeing these
kinds of discussions.
- 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.
