Granting a capability to a service
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.
More information about the devel