Re: [PATCH] support cap inheritable (Re: [PATCH] scaled-back caps, take 4 (was Re: [PATCH] capabilites, take 2)

[Chris Wright <chrisw@osdl.org>]

* Andy Lutomirski (luto@myrealbox.com) wrote:
> Chris Wright wrote:
> 
> > -#define CAP_INIT_INH_SET    to_cap_t(0)
> > +#define CAP_INIT_INH_SET    to_cap_t(~0)
> > +/* ~0 is legacy inheritable mode and can never be capset by user */
> > +#define cap_orig_inh(_cap) (cap_t((_cap)) == ~0)
> 
> So how do you say "inherit all caps"?

Legacy mode requires effectively reserving a bit, which works in this case
since all 32 aren't used.  So inherit all caps is all valid caps (which,
btw,  still exludes CAP_SETPCAP).  Something like "=eip cap_setpcap-eip"
would inherit all valid caps.

> > @@ -56,10 +59,13 @@
> >  int cap_capset_check (struct task_struct *target, kernel_cap_t *effective,
> >  		      kernel_cap_t *inheritable, kernel_cap_t *permitted)
> >  {
> > +	kernel_cap_t target_inheritable = target->cap_inheritable;
> > +	if (cap_orig_inh(target_inheritable))
> > +		target_inheritable = 0;
> >  	/* Derived from kernel/capability.c:sys_capset. */
> >  	/* verify restrictions on target's new Inheritable set */
> >  	if (!cap_issubset (*inheritable,
> > -			   cap_combine (target->cap_inheritable,
> > +			   cap_combine (target_inheritable,
> >  					current->cap_permitted))) {
> >  		return -EPERM;
> >  	}
> 
> What stops legacy mode from being reenabled?

I believe only a kernel thread could do this (and init) since they are the
only ones that could get CAP_SETPCAP.  Same threat as it is currently.

> I think you missed the case when root-but-no-caps execs setuid root -- I 
> don't see anything that would enable secureexec.

Yup you're right.  I liked how you did that in your patch and was just going
to steal that bit ;-)

thanks,
-chris
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net