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. >>>> The only way to bypass that >>>> if you perform the execve call with UID 0 (i.e., the literal UID 0, not >>>> a capability). >>> >>> >>> >>> Using libcap-ng, its 3 lines of code. Assuming the desired uid is 500: >>> >>> capng_clear(CAPNG_SELECT_BOTH); >>> capng_update(CAPNG_ADD, CAPNG_EFFECTIVE|CAPNG_PERMITTED, >>> CAP_NET_BIND_SERVICE); if (capng_change_id(500, 500, CAPNG_DROP_SUPP_GRP | >>> CAPNG_CLEAR_BOUNDING)) error(); >> >> But this requires changing the implementation of the service, right? > > Yes. But doing this is so simple, that it shouldn't be a big deal. 3 lines of > code. Ugh, not really. Not if code creates threads before (the equivalent of) the main() function is called. glibc has code to deal with that (the setxid business). It is rather scary, but it does not cover capabilities (we could change that), and does not help with binaries which do not link against glibc (which is more difficult to change). -- Florian Weimer / Red Hat Product Security -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
