Re: [PATCH] capabilities: Ambient capability set V1

["Serge E. Hallyn" <serge-A9i7LUbDfNHQT0dZR+AlfA@public.gmane.org>]

On Mon, Feb 23, 2015 at 11:19:29PM -0600, Serge E. Hallyn wrote:
> On Mon, Feb 23, 2015 at 06:15:53PM +0000, Serge Hallyn wrote:
> > Quoting Christoph Lameter (cl-vYTEC60ixJUAvxtiuMwx3w@public.gmane.org):
> > > On Mon, 23 Feb 2015, Serge E. Hallyn wrote:
> > > 
> > > > > I do not see a problem with dropping privilege since the ambient set
> > > > > is supposed to be preserved across a drop of priviledge.
> > > >
> > > > Because you're tricking the program into thinking it has dropped
> > > > the privilege, when in fact it has not.
> > > 
> > > So the cap was dropped from the cap perm set but it is still active
> > > in the ambient set?
> > 
> > Right, and the legacy program doesn't know to check the new set.
> 
> we've been assuming the ambient set must be like fP.  is there any
> reason why it doesn't suffice for them to be or'ed with fI instead at
> exec?  then the bits would need to ne in pI. this might sufice for
> Christoph's use case, as pI will generally not change.  and for programs
> that really care, they can check pI.

The other way to look at it then is that it's basically as though the
privileged task (which has CAP_SETFCAP) could've just added fI=full to
all binaries on the filesystem;  instead it's using the ambient set
so that the risk from fI=full is contained to its own process tree.