[Cvsnt] [jakomail at emss.co.za: Re: User context switch in sshd using RSAAuthentication]

[Corinna Vinschen]

----- Forwarded message from Ulrich Jakobus <jakomail at emss.co.za> -----
Date: Thu, 06 Dec 2001 21:14:26 +0200
From: "Ulrich Jakobus" <jakomail at emss.co.za>
Subject: Re: User context switch in sshd using RSAAuthentication
To: "cygwin at cygwin.com" <cygwin at cygwin.com>
Reply-To: "Ulrich Jakobus" <jakomail at emss.co.za>

May be here a reply that I got from the CVSNT list on this issue
(claiming that this is a problem of Cygwin/sshd):

On Thu, 6 Dec 2001 08:45:36 -0800, Terris wrote:

>Are you using SSH password authentication or SSH public key authentication?
>
>cygwin's openssh server has a bug whereby if you use public key
>authentication, the user is the user's that's running the sshd daemon rather
>than the remote user.  The cygwin folks claim it's due to a problem with NT,
>(funny how that's always the fall-back position for programmers)
>but it's actually a problem with their understanding of NT.  They need to
>look at the CVSNT 1.11.1.2 pserver code.
>
>If you really have to use public key authentication, use
>VanDyke's vshell.  http://vandyke.com
[...]
----- End forwarded message -----

Hi,

I'm the developer who added the NTCreateToken stuff to Cygwin.  I have
to make some points and questions here.

First of all, the above description isn't fully correct.  The Cygwin
OpenSSH has no idea about the NT way of changing user context w/o
password.  The implementation is inside of the Cygwin DLL.  OpenSSH
is using the setuid() call.  I'm just wondering about the above
message since you should know that.  The big comment at the beginning
of setuid.c is claiming that the setuid() code is based on my Cygwin
implementation.

The problem with the user name is something which really bugs me and
I'm hoping somebody actually knows how to solve that.

Anyway, the problem is the following.

Imagine the NtCreateToken() call is successful in Cygwin, now we call
ImpersonateLoggedOnUser() or later when executing a child process we
call CreateProcessAsUser().

If you now take a look into the Task Manager, you'll see the new
child process is actually running under the new account name.

But _inside_ of the new child process it can't retrieve its own
user name correctly.  If the NtCreateToken is called by a process
running under account `foo', changing to account `bar', a call
to GetUserName() in a child process running under `bar' returns
`foo'!  Ok, if I can't rely on the GetUserName() info, let's
call LookupAccountSid() with the own `bar' SID.  Nevertheless,
even LookupAccountSid() returns the user name `foo'!

So the system knows that the process is running under account `bar'
but the process itself can't get that user name.  It knows it's
SID, but no NT function returns the correct user name coupled to
that SID.

I can workaround that in Cygwin for all POSIX calls which retrieve
user information but I can't change the return values of Win32
functions, obviously.

I looked into the pserver implementation of cvsNT per your suggestion
but from what I see cvsNT has the advantage that it doesn't use
GetUserName() or LookupAccountSid() _after_ changing the user context
but before.  It stores the user name and uses it later on.  So it's
no wonder that cvsNT can syslog the correct user name.

OTOH, if it's called from Cygwin's OpenSSH, it retrieves the user
name _after_ the user context switch has happened.  Now it suffers
from the same problem as all processes using Win32 calls to retrieve
the user name.

I found a piece of new code in cvsNT's setuid() which isn't in my
implementation.  It adds a Logon ID (S-1-5-5-xxx-yyy) to the group
list.  First I thought that my problem is related to the fact that
my tokens don't have that Logon ID but adding the Logon ID to the
token's group list and adding SE_GROUP_LOGON_ID to the group's
attributes didn't change the above behaviour, unfortunately.

However, I don't see any other difference in the sources.  Do you
have a hint or at least an idea what's going wrong?

Please keep me Cc'd since I'm not subscribed to the cvsnt list.

Thanks,
Corinna

--
Corinna Vinschen
Cygwin Developer
Red Hat, Inc.
mailto:vinschen at redhat.com
_______________________________________________
Cvsnt mailing list
Cvsnt at cvsnt.org
http://www.cvsnt.org/cgi-bin/mailman/listinfo/cvsnt