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

[Terris]

Hi,

I just wanted everyone here to know that Corinna and
I discussed this offline.  Corinna brings up some
issues that I obviously was not aware of.  It seems that
CVSNT is working around a real problem in the NT
kernel in which all attempts to get the effective user
name or SID returns 'SYSTEM', which sucks hard.

I had discussed this before on a previous list
(ssh-d) and this is the first time I've heard the facts
and I appreciate Corinna for taking the time to
educate me.

At any rate, VanDyke's vshell works, so I wonder
what they do.  Unless Tony and Corinna can find
a solution, I don't think cygwin's openssh implementation
is very usable unless you use password
authentication, which I think is fine for the majority
of CVS users.

Perhaps openssh should not even
claim to support public key authentication?  It
just generates email traffic like this.  There should
at least be some sort of disclaimer.  I
warn the readers of devguy.com at
http://devguy.com/fp/cfgmgmt/cvs/cvs_ssh.htm,
but that page reaches a small minority of the NT
SSH population.

"Corinna Vinschen" <vinschen at redhat.com> wrote in message
news:20011207125017.K740 at cygbert.vinschen.de...
> ----- 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


_______________________________________________
Cvsnt mailing list
Cvsnt at cvsnt.org
http://www.cvsnt.org/cgi-bin/mailman/listinfo/cvsnt