Bug#756604: systemd: NoNewPrivileges allows UID changes, while the doc says it prohibits it

[Ansgar Burchardt]

On 07/31/2014 11:53, Ansgar Burchardt wrote:
> On 07/31/2014 11:42, intrigeri at 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