Aleksandar Kostadinov
2017-Aug-06 19:44 UTC
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/
Damien Miller
2017-Aug-07 00:13 UTC
deprecation of UsePrivilegeSeparation breaks container use cases
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
Darren Tucker
2017-Aug-07 00:17 UTC
deprecation of UsePrivilegeSeparation breaks container use cases
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.
Aleksandar Kostadinov
2017-Aug-07 16:39 UTC
deprecation of UsePrivilegeSeparation breaks container use cases
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 <...>
Seemingly Similar Threads
- Is support being removed for ordinary users to run sshd?
- [Bug 230] UsePrivilegeSeparation turns off Banner.
- PermitRootLogin=forced-commands-only does not work with UsePrivilegeSeparation=yes
- [Bug 283] UsePrivilegeSeparation fails on AIX, Couldn't set usrinfo:
- Problems with UsePrivilegeSeparation (was: port fwd as user != root?