Messages in this thread | | | Date | Tue, 24 Feb 2015 09:47:15 -0600 | From | "Serge E. Hallyn" <> | Subject | Re: [PATCH] capabilities: Ambient capability set V1 |
| |
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@linux.com): > > > 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.
| |