On Mon, Jul 20, 2015 at 2:34 PM, Steve Grubb <sgrubb@xxxxxxxxxx> 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@xxxxxxxxxx> wrote: >> > On Monday, July 20, 2015 11:09:39 AM Andrew Lutomirski wrote: >> >> On Jul 20, 2015 11:05 AM, "Florian Weimer" <fweimer@xxxxxxxxxx> 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. --Andy -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
