openssh bugs - Jul 2018 - [Bug 2885] New: sshd is not using chroot and privsep on default cygwin install any more

https://bugzilla.mindrot.org/show_bug.cgi?id=2885

            Bug ID: 2885
           Summary: sshd is not using chroot and privsep on default cygwin
                    install any more
           Product: Portable OpenSSH
           Version: 7.7p1
          Hardware: Other
                OS: Cygwin on NT/2k/W7/W8/W10
            Status: NEW
          Severity: security
          Priority: P5
         Component: sshd
          Assignee: unassigned-bugs at mindrot.org
          Reporter: Christian.Lupien at USherbrooke.ca

I think that since commit d13281f2964abc5f2e535e1613c77fc61b0c53e7
sshd under cygwin is no longer using privsep by default.

I was trying to test which sshd account the program was using for
privsep (I had a local and a domain sshd account). However I was unable
to see any use of it (nor any errors). I looked at the "ps -a" output,
also at the output of "sshd -d -d -d" and even tried strace but could
not find it anywhere.

I then looked at the code. Most the places in the code where
  getuid() == 0
is used it the code is special cased for cgywin but the change
introduced by the commit d13281f2964abc5f2e535e1613c77fc61b0c53e7 did
not.

Therefore, privsep under cygwin seems to be disabled unless the account
under which sshd is executed is forced to have uid=0 (by changing the
/etc/passwd file).

I did try the forcing uid=0 in the passwd file and that worked (I saw
the sshd account being used and chroot executed.)

I have not tried modifying the code and recompiling it but probably
replacing (part of line 1734)
  getuid() == 0 || geteuid() == 0
with
  platform_privileged_uidswap()
would work.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2885

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |djm at mindrot.org

--- Comment #1 from Damien Miller <djm at mindrot.org> ---
I don't understand how commit d13281f2964 changed this behaviour - it
replaced the inline getuid() checks with one performed in main() and
there has never AFAIK been special-casing for Cygwin around this check.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2885

--- Comment #2 from Christian.Lupien at USherbrooke.ca ---
You are right. I guess I thought it used to work and was looking at
something that changed. But, as you say, that commit did not change the
main behavior.

So I guess this means the behavior of chroot and prvisep account not
being used on cygwin (with uid !=0, which is the default) has been this
way for a long time.

It should be fixed or documented.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2885

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |vinschen at redhat.com

--- Comment #3 from Damien Miller <djm at mindrot.org> ---
Corinna, what do you think the right behaviour is here?

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2885

--- Comment #4 from Corinna Vinschen <vinschen at redhat.com> ---
Privsep never worked fully on Cygwin.  It uses descriptor passing via
AF_UNIX sockets which isn't implemented in Cygwin (yet).

So when privsep was introduced, only one half of it got used on Cygwin.
The problem is, I don't remember which part of it.

Either way, I checked the source history and it seems the code
in question here (preauth) was never used on Cygwin anyway.  The
getuid==0 check exists since 2002.

Second problem is that permanently_set_uid() is a fake on Cygwin.
Permanently changing the uid/gid only works when exec'ing a new
process.  It's never permanent while still in the same process.
This is a limitation of the Windows authorization model.

Above all, chroot is a concept not supported by Windows anyway.
Therefore the chroot emulation of Cygwin does not actually
add any security since applications can easily work around it
by using native Windows API calls rather than just Cygwin
POSIX calls, as is well-known.

Bottom line is, I'm not sure what to do here.  Preauth privsep
is not really well supportable on Cygwin.  Probably the best way
out is to remove any Cygwin-specific code here and tell the user
that this is not supported on Cygwin.

THis shouldn't affect the other part of privsep, though.


Corinna

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2885

Darren Tucker <dtucker at dtucker.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dtucker at dtucker.net

--- Comment #5 from Darren Tucker <dtucker at dtucker.net> ---
(In reply to Corinna Vinschen from comment #4)
> Privsep never worked fully on Cygwin.  It uses descriptor passing
> via AF_UNIX sockets which isn't implemented in Cygwin (yet).
> 
> So when privsep was introduced, only one half of it got used on
> Cygwin.
> The problem is, I don't remember which part of it.
If the sticking point is descriptor passing then that's used for pty
allocation in post-auth privsep, so that would make preauth the working
part.

There used to also be an anonymous mmap thing that got used for zlib
state passing, but since preauth zlib is now gone that shouldn't be an
issue.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.