Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Thu, 6 Jan 2011 21:26:26 -0500 (EST)
From: "Steven M. Christey" <>
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:
>> 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.