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

2014-07-31 Thread intrigeri
Control: retitle -1 Misleading documentation about NoNewPrivileges and UID 
changes
Control: tag -1 + upstream

Hi,

Ansgar Burchardt wrote (31 Jul 2014 09:53:21 GMT) :
 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.

Thanks a lot! I'll report a bug upstream (possibly with a patch) wrt.
the documentation being a bit misleading, then.

Cheers,
-- 
intrigeri

___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers


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

2014-07-31 Thread intrigeri
Hi again,

Ansgar Burchardt wrote (31 Jul 2014 10:04:52 GMT) :
 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.

Indeed, this won't affect the tor service: my intention is to use
AppArmorProfile= in its unit file as soon as systemd v210+ is
available in Debian, to replicate how we're doing it in the
initscript. I'll double-check once we're at this point, though.

Cheers,
-- 
intrigeri

___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers