deprecation of UsePrivilegeSeparation breaks container use cases

[Darren Tucker]

On Mon, Aug 7, 2017 at 5:44 AM, Aleksandar Kostadinov <akostadinov at gmail.com
> wrote:

> Hello,
>
> 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
this commit:
https://anongit.mindrot.org/openssh.git/commit/?id=d13281f2964abc5f2e535e1613c77fc61b0c53e7
it won't require the user or dir.

As I said last time this came up:
https://lists.mindrot.org/pipermail/openssh-unix-dev/2017-March/035906.html
Disabling privsep will not be supported.  Running as an unprivileged user
is supported in the two-process configuration.

I understand that privilege separation [1] 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
> users.
>
> 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
and configurations).

[...]

> Do you have other ideas how container use cases can be covered in the
> future without giving the users dangerous privileges?
>

See above.

-- 
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.