oss-security January 2011 archive
Main Archive Page > Month Archives  > oss-security archives
oss-security: Re: [oss-security] CVE-NONE kernel: PHONET signedn

Re: [oss-security] CVE-NONE kernel: PHONET signedness issue

From: Steven M. Christey <coley_at_nospam>
Date: Fri Jan 07 2011 - 02:26:26 GMT
To: oss-security@lists.openwall.com

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