Re: [PATCH] + story;) on POSIX capabilities and SUID bit

Marek Zelem (marek@terminus.sk)
Wed, 17 Apr 2002 18:06:48 +0200 (CEST)


On 16 Apr 2002, David Wagner wrote:

> Marek Zelem wrote:
> >Our new formula:
> > * (***) pP' = (fP & X) | (fI & pI)
> > * pI' = pP'
> > * pE' = ((pP' & pE) | fP) & X & fE
>
> Can you say anything about why this is safe and doesn't introduce
> vulnerabilities? (The capabilities misfeature that caused sendmail
> 8.10.1 to leak root privilege really drove home for me the subtlety of
> this stuff.)

New 'permitted' capabilities for process are computed by the same formula as
the original because there is the primary aspiration to preserve the original
POSIX formula.
Most significat difference is in computation of 'inheritable' capabilities.
Original formula just keeps process 'inheritable' capabilities untouched.
(This fact was major problem of consolidate POSIX capabilities and SUID bit.)
New formula set the 'inheritable' capabilities to correspond with the new
'permitted'.
There can occur four situations:
1) capability was in pI and will be in pI' - this correspond with
the original formula
2) capability wasn't in pI and will not be in pI' - this also
correspond with the original formula
3) capability was in pI and will not be in pI' - (so is not set
in new pP) - meaning: proces is NOT able to raise self pP by
executing "nosuid" binary. In this case is new formula
more restrictive then original.
4) capability wasn't in pI and will be in pI' - this can occure
only if this capability is in fP. In this case this
capability is also in pP'. And if is in 'permitted' caps
then process is allowed to add this capability into
'inheritable' caps. So we do nothin wrong if we set this
capability into pI'.
Finally, difference in computation of pE' only aspirate to reflect pE.
Major principle was preserved: pE' = pP' & fE. In new formula was pP'
replaced by more complex term. But it's always true that
(((pP' & pE) | fP) & X & fE) IS SUBSET of (pP' & fE).
So I think this is safe.

>
> Also, the meaning of fE and fP seem backwards from what I would have
> expected. Maybe this reflects a lack in my understanding in capabilities,
> but I thought 'effective' refers to capabilities you're allowed to invoke
> at the moment, whereas 'permitted' refers to an upper bound on what
> capabilities you're allowed enable in 'effective', consequently I would
> have swapped the treatment of fE and fP. Can you clear up my confusion?

File capabilities are little different from process capabilities. Meaninig
of file capabilities is:
fP - capafilities which are "forced" to process by exec().
(sometimes called 'forced' capabilities)
fI - capabilities which is "allowed" to remain in process 'permited'.
(sometimes called 'allowed' capabilities)
fE - capabilities which select which of 'permited' will be
initially also 'effective'. (afrer exec() of course.)

>
> Finally, what's the story behind the changes to CAP_INIT_EFF_SET and
> CAP_INIT_INH_SET, and the business with CAP_SETPCAP? If I understand
> correctly, one side-effect of this change is that you've changed cap_bset
> (X, the global bound on capabilities above) to add CAP_SETPCAP to it.
> Is this safe? What motivated this change? Did I understand correctly?

Yes, you understand correctly. Enabling CAP_SETPCAP is safe exactly as
enabling the CAP_SYS_MODULE, which is enabled by default. Capability
CAP_SYS_MODULE allows process to modify the cap_bset. Maybe I am wrong,
but my opinion is not to do inconsequential restrictions. So, this is
reason why I decide to change CAP_INIT_EFF_SET.

Marek Zelem

--
  e-mail: marek@terminus.sk
  web: http://www.terminus.sk/~marek/
  pgp key: http://www.terminus.sk/~marek/gpg.txt

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/