Subauthentication

[Hartmut Honisch]

Corinna,

the other day we talked about cygwin's setuid problem under Windows
NT/2K/XP. I suggest that we re-enable subauthentication, because it has the
advantage that it correctly changes the Windows security context a
process/thread runs in. The current solution with NTCreateToken doesn't
correctly handle all situatuions.

I've mainly been testing with ssh and public key authentication. The sshd is
installed as Windows service, running under the LocalSystem account. When I
use an ssh client (and public key authentication) to connect to the sshd as
"MyUser", the session should run in the security context "MyUser". Howerver,
all calls to Windows' GetUserName() or similar functions always return the
LocalSystem account. Therefore, I effectively have the permissons of
LocalSystem when accessing secured objects on the target system. This is no
good.

If I remember correctly, you problem was that you got subauthentication
working only under Win2K, and not on XP and NT 4. I don't see why it
shouldn't work on XP (it did when I tried it on my PC), but NT was a generic
problem. The Lsa* functions that I need to call for subauthentication are
not exported by any DLL on NT - on 2K and XP, secur32.dll exports them.

I found out that Microsoft's freely available NT 4 Driver Development Kit
contains a library "lsadll.lib" that actually _implements_ those functions,
i.e. the code for the Lsa* stuff is _in_ that lib-file, and not in a system
DLL. And I have _no_ idea how the source code to that lib-file looks like,
so at least for now, I guess we have to use the lib-file itself, which
probably raises some legal issues (see below).

So, to make subauthentication work on NT, cygwin1.dll (which contains the
setuid-stuff) would have to link to lsadll.lib, rather than loading the lsa*
functions from secur32.dll

Unfortunately, lsadll.lib imports some functions exported by ntdll.dll.
Microsoft's documentation advises the programmer to link to ntdll.lib,
another file contained in the NT4 DDK, which is used to statically link to
ntdll.dll. However, I would assume that if cygwin1.dll was statically linked
to lsadll.lib and ntdll.lib, it wouldn't work any more on 9x-Systems,
because ntdll.dll would be missing, right?

Maybe there would be a way to link cygwin.dll to lsa.lib and load the
required ntdll-functions by using the autoload stuff. But the way I solved
the problem was to create a new dll (/bin/cyglsa.dll) that exports the
required lsa* functions - a dll that works on NT, 2K and XP. And I changed
autoload.cc to load the lsa functions from cyglsa.dll, and not from
secur32.dll. So cygwin on Win9x should still work (I haven't tested it yet -
only tried NT, 2K and XP so far). (Essentially, we create our _own_
secur32.dll ...)

With those changes and your subauth-module, subauthentication works fine.
You don't even have to copy the cygsuba.dll to the system32 directory - just
copy it into /bin and write the whole path to the registry. And users who
want to use subauthentication need some additional Windows privileges that
are not granted by default: SE_TCB_NAME, SE_ASSIGNPRIMARYTOKEN_NAME and
SE_INCREASE_QUOTA_NAME.

I see a legal issue though. If I understand the NT4 DDK license agreement
correctly, we're not allowed to freely distribute  lsadll.lib and ntdll.lib
(even though it's available for free), which would be required to create
cyglsa.dll. However, we should are allowed to use the lib-files to create a
dll (=> cyglsa.dll) and distribute that dll instead. If a developer wants to
build cyglsa.dll himself, he'll have to download the NT4 DDK from somewhere,
but I think that will be necessary very rarely.

Finally some remarks to using network resources. Subauthentication is only
supported for network logons, and those don't create logon sessions. So, at
first, when I was in a ssh session and wanted to connect network resources,
Windows' "net use" returned an error message telling me that there was no
active logon session. But there is a workaround for that: _Always_ specify
username and password ("net use \\server\share mypassword
/user:Domain\user"), and you _will_ be able to connect to the network
resources.

So, what do you think?

-Hartmut