On 07/31/2014 11:53, Ansgar Burchardt wrote: > On 07/31/2014 11:42, intrig...@debian.org wrote: >> the attached unit file has NoNewPrivileges set to "yes", which, >> according to systemd.exec(5), "prohibits UID changes of any kind". >> >> However, the tor daemon it starts successfully manages to change its >> UID to debian-tor, as configured with "User debian-tor" in >> /usr/share/tor/tor-service-defaults-torrc: > [...] >> Did I misunderstand the documentation, or is the doc wrong, or is >> there a bug somewhere? > > It works as intended, but the documentation might be a bit misleading. > NoNewPrivileges only affects the exec syscall which will no longer grant > any new privileges, including no longer switching uid for suid binaries. > It does *not* take away the CAP_SETUID or any other capabilities the > process already has.
Oh, and one other thing that might be worth mentioning in this context: | Be careful, though: LSMs might also not tighten constraints on exec | in no_new_privs mode. (This means that setting up a general-purpose | service launcher to set no_new_privs before execing daemons may | interfere with LSM-based sandboxing.) +--[ Documentation/prctl/no_new_privs.txt ] I have no idea about LSMs, but I would expect this to only matter if you either rely on the kernel to setup the sandbox for the service (and do not use AppArmorProfile=) or if the service executes programs that should have even tigher restrictions. Both of which should not affect services like tor, but might be relevant for others. Ansgar -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
