Re: understanding Linux capabilities brokenness

[David Madore <david.madore@ens.fr>]

Sorry for replying to myself...

On Mon, Aug 08, 2005 at 09:13:06PM +0000, David Madore wrote:
> However, what I do not understand is precisely _how_ one gets a
> sendmail process without CAP_SETUID: for that is the heart of the
> problem, and that is where the bug really was.  But [#3] and [#4] are
> very obscure (and I found nothing conclusive in lkml archives).  I
> understand that the problem lies in some combination of the
> inheritable capability set and the CAP_SETPCAP capability, but I don't
> see what that combination is.  Certainly removing capabilities from
> the inheritable set should not prevent suid root programs from having
> them reinstated (in the language of [#6], the suid root bit should
> correspond to a full forced set of capabilities), so I don't see what
> that has to do with it, and CAP_SETPCAP indeed allows to remove
> capabilities from a given process but I don't see how the user could
> gain that capability (and indeed if he can then we can expect him to
> gain all capabilities very rapidly).

After some more intensive Googling, I found the answer in the archives
of the linux-privs-discuss mailing-list (whose existence I did not
know of):

<URL:
http://sourceforge.net/mailarchive/forum.php?thread_id=1588083&forum_id=25120
 >

The explanation from the sendmail team was incorrect: CAP_SETPCAP is a
red herring, it's only about CAP_SETUID, the implementation of the
inheritable set was broken in that it controlled not only capabilities
automatically passed across execve() but also those _gained_ by suid
root programs (contrary to the claim in the sendmail analysis) and,
worse, instead of failing on execve() when the program could not gain
privileges, it proceeded with the capabilities missing.  Hence the
catastrophic failure.

This does not tell me, then, why CAP_SETPCAP was globally disabled by
default, nor why passing of capabilities across execve() was entirely
removed instead of being fixed.

-- 
     David A. Madore
    (david.madore@ens.fr,
     http://www.madore.org/~david/ )