|Main Archive Page > Month Archives > oss-security archives|
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 . 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.