On Jul 18, 2015 1:42 AM, "Florian Weimer" <fwei...@redhat.com> wrote: > > Let's assume I want to start a service as an ordinary user, but allow to > bind it to a privileged port. The program implementing the service does > not manipulate capabilities in any way. > > I came up with with this system unit for testing purposes: > > [Unit] > Description=Test unit > > [Service] > Type=oneshot > ExecStart=/usr/sbin/getpcaps self > Capabilities=cap_net_bind_service+ep > SecureBits=keep-caps > User=fweimer > StandardOutput=journal > > However, this does not work, the capability set remains empty. Is there > a way to achieve what I want? > > The algorithm documented in capabilities(7) suggests that retaining > effective capabilities across an execve system call absolutely requires > file capabilities (the inheritable part). The only way to bypass that > if you perform the execve call with UID 0 (i.e., the literal UID 0, not > a capability). > > This design is really odd because setting file capabilities always > increases the attack surface (even if it is just the inheritable bits), > and the only alternative appears to modify the service so that it is > capability-aware and switches away from UID 0, and grant sufficient > capabilities so that it can do so. At that point, you can just skip the > configuration in the systemd service and do everything capablity-related > within the program. > > What am I missing?
Nothing. Inheritable capabilities are nearly useless. The thing you want is called "ambient" capabilities and should be available in Linux 4.3. --Andy > > -- > Florian Weimer / Red Hat Product Security > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
