openssh unix dev - Aug 2017 - deprecation of UsePrivilegeSeparation breaks container use cases

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

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.

Unfortunately I see that in 7.5 the privilege separation option is
being deprecated [2]. Other users have raised concerns earlier [3][4]
but I don't find much explanation why they were not taken into
account.

I think it will be beneficial for a lot of users to keep the option
present. Container users becoming more and more every day thus IMO
container use cases need to be very well covered.

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

Thank you,
Aleksandar

[1] http://www.citi.umich.edu/u/provos/ssh/privsep.html
[2] https://www.openssh.com/txt/release-7.5
[3] https://news.ycombinator.com/item?id=13213174
[4] https://lwn.net/Articles/717553/

On Sun, 6 Aug 2017, Aleksandar Kostadinov 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`.
> 
> 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.
It's not much of a container if it doesn't contain root-running code
IMO.

Anyway, running sshd as a non-root user works fine and will continue
to work fine. Making privsep mandatory for root-started sshd hasn't
changed this.

-d

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.

On Mon, Aug 7, 2017 at 3:17 AM, Darren Tucker <dtucker at zip.com.au>
wrote:
> On Mon, Aug 7, 2017 at 5:44 AM, Aleksandar Kostadinov
> ...
> 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.
Thanks a lot for pointing me at the right direction. I tested with
SSHd 7.5p1 and also with 7.4p1. It works running as unprivileged user
(username `git`) using priv separation! Output reformatted for
readability:

-bash-4.3$ cd /proc
-bash-4.3$ cat 1/cmdline
/usr/sbin/sshd-D
-bash-4.3$ cat 57/cmdline
sshd: git [priv]
-bash-4.3$ cat 60/cmdline
sshd: git at pts/0
-bash-4.3$ cat 61/cmdline
-bash

<...>