Granting a capability to a service

Steve Grubb sgrubb at redhat.com
Mon Jul 20 21:34:51 UTC 2015


On Monday, July 20, 2015 12:45:28 PM Andrew Lutomirski wrote:
> On Mon, Jul 20, 2015 at 12:26 PM, Steve Grubb <sgrubb at redhat.com> wrote:
> > On Monday, July 20, 2015 11:09:39 AM Andrew Lutomirski wrote:
> >> On Jul 20, 2015 11:05 AM, "Florian Weimer" <fweimer at redhat.com> wrote:
> >> > On 07/20/2015 05:59 PM, Steve Grubb wrote:
> >> > > Today, any application that wants to manipulate capabilities needs to
> >> > > be
> >> > > capability aware.
> >> > 
> >> > The application does not want to manipulate capabilities.  I do not
> >> > want
> >> > to run it as full root.  I don't want to add additional SUID/fscaps to
> >> > the file system.
> >> > 
> >> > It's somewhat silly to add a privilege escalation hatch to the file
> >> > system in order to run a daemon with *reduced* privileges.
> >> 
> >> This is exactly why the ambient caps patch is sitting in -mm.  If you
> >> want
> >> to read it and email a quick review, that might help it along.  :)
> > 
> > The real problem with capabilities is there is no way to say, I trust this
> > child process with this capability, but don't let it get inherited beyond
> > this process that I'm about to start.
> 
> Why would you want to do that?

Because you know exactly why the program needs a capability and its not known 
to have children. Therefore any children must be because of an exploit. The 
way it is, capabilities are inherited and you can't stop it.

-Steve



More information about the devel mailing list