On 07/18/2015 03:53 PM, Andrew Lutomirski wrote: > Nothing. Inheritable capabilities are nearly useless. Wow. The program that sparked this thread is a Go program. So basically, we have these options if we do not want to run with full capabilities: (a) Run with UID=0 with restricted capabilities, like many systemd services already do. Do not use fscaps (which are not needed because of the UID=0 special case). This is rather pointless because UID=0 does not need capabilities to compromise the system. (b) Make a copy of the file, put it in a directory which only the service user can read (or ship it with 750 permissions and the service group controlling it), and set fscaps. The downside is the large binary size (it has to be a copy, a link won't work). And the service user could still run the service with command line options that allow privilege escalation. (c) Make a copy as above, but in a directory only readable by root. Add fscaps and make the binary SUID/SGID to service user/group. This prevents privilege escalation by the service user (because it won't be able to execve the SUID/SGID/fscaps binary, and ptrace of the privileged process is blocked). The service might end up running with unintended supplementary groups, though. And there is the copy overhead. (d) Change the Go program to optionally drop capabilities and switch the user. Do not use fscaps, and keep running it as full root initially. This is the cleanest approach and what other services use, but I don't think Go currently supports switching credentials in all threads in the process. (e) Have a helper/wrapper which does (d) and invokes the Go program after all the work which requires capabilities. Downsides are that this not very general and works only for very specific use cases. It also interferes with built-in restarts of the service daemon (the restart would have to be performed by systemd). Ignoring the file copy overhead, (c) looks most promising. Thoughts? -- 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
