Re: CVE-NONE kernel: PHONET signedness issue

["Steven M. Christey" <coley () rcf-smtp mitre org>]

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