Granting a capability to a service
luto at mit.edu
Mon Jul 20 21:50:32 UTC 2015
On Mon, Jul 20, 2015 at 2:34 PM, Steve Grubb <sgrubb at redhat.com> wrote:
> 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.
I assume you mean that it's known not to have children. That's a
somewhat unusual thing to know about a program.
> Therefore any children must be because of an exploit. The
> way it is, capabilities are inherited and you can't stop it.
Programs that can usefully drop capabilities should do so. Having the
program's caller specifically rig it so that execve drops capabilities
seems next to useless as a mitigation technique -- an attacker will
simply refrain from using execve in their exploits.
More information about the devel