deprecation of UsePrivilegeSeparation breaks container use cases
dtucker at zip.com.au
Mon Aug 7 10:17:09 AEST 2017
On Mon, Aug 7, 2017 at 5:44 AM, Aleksandar Kostadinov <akostadinov at gmail.com
> there are emerging container services that restrict regular users to
> launch containers under some random uid for security reasons. If such
> user needs sshd in their container, they need to turn off
> `UsePrivilegeSeparation` so that sshd is executed as the current uid
> and not `root`.
That's not accurate. As of 7.5p1 it required that the privsep user and dir
exist but as long as they do it'll work as an unprivileged user. As of
it won't require the user or dir.
As I said last time this came up:
Disabling privsep will not be supported. Running as an unprivileged user
is supported in the two-process configuration.
I understand that privilege separation  is more than changing the
> process uid. On the other hand, it is unreasonable to expect
> administrators to let regular users execute privileged code of any
> sort. If they do so, this would compromise security of all other
> And I can't see how privilege separation can work without giving
> regular users elevated privileges of some sort. Especially giving
> users `chroot` privileges would be highly dangerous.
It's not just chroot. There are some protections that work even
unprivileged (eg OpenBSD's pledge or the admittedly weak rlimit sandbox)
and removal of the !privsep code paths will reduce complexity (both code
> Do you have other ideas how container use cases can be covered in the
> future without giving the users dangerous privileges?
Darren Tucker (dtucker at zip.com.au)
GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new)
Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.
More information about the openssh-unix-dev