Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-developers-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-developers-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-developers-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin-developers AT sources DOT redhat DOT com
Date: Sun, 20 May 2001 10:49:16 +0200
From: Corinna Vinschen <vinschen AT redhat DOT com>
To: cygdev <cygwin-developers AT cygwin DOT com>
Subject: Authentication without password: 2nd try.
Message-ID: <20010520104916.A16551@cygbert.vinschen.de>
Reply-To: cygdev <cygwin-developers AT cygwin DOT com>
Mail-Followup-To: cygdev <cygwin-developers AT cygwin DOT com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i

Hi all,

I have just added a 1500 lines patch to Cygwin which implements the
2nd way to change the user context without providing a password:

Creating a token by using the (undocumented) NtCreateToken call.

To say that first: This time I tested it on W2K _and_ NT4!

The new way of getting a token:

- The account which wants to change the user context needs the
  SE_CREATE_TOKEN_NAME "Create a token object" privilege.

  That's true by default only for LocalSystem and it's recommended
  not to change that. However, for testing purposes or for creating
  a special account for login purposes it's ok.

- As usual, the functionality is most happy with well maintained
  /etc/passwd and /etc/group files. /etc/group isn't that important,
  though, but adding all groups used as primary groups _with_ SID
  is recommended.

- seteuid now tries first to create a token directly. If that fails
  it falls back to trying subauthentication (which needs the SE_TCB_NAME
  "Act as part of the operating system" privilege).

- The token created by the new `create_token' function (security.cc)
  gets the same authentication id as the process token. That has the
  following effect:

  - If the process is running under LocalSystem account, the auth id
    is the default system auth id which has only permissions to
    access network shares which are open to everyone. Note that
    this is different from open to all authenticated users! If one
    has to give a password to access a share, that share is not
    accessible from here.

  - If the process is running under any authenticated user account,
    the new token inherits the network access rights of the process.
    Each network share is accessible with the same permissions as
    the process owner have.

  After the above description you probably guess that the user
  don't has her own access rights on network shares as she would
  have if logged on interactively. You guess right.
  The problem is that the token don't have an unique authentication
  id which is related to a logon session created by an interactive
  logon of that very user.

Please give it a try. Personally I have used "su", a patched version of
"sshd" and my test application which I already sent to this group in
the thread " New subdirectory in winsup" for testing.

The patch to sshd is actually reverting a patch I did months ago.
That original patch prevents sshd from changing the user context
if now password authentication was made which is obviously not
what we want anymore. ;-)

If you want to use "su" for testing, don't fall for the "su -" trap
as I did! I have desparately searched for an error in my code since
"su -" didn't correctly change the user context for some reason, while
my own test app, "su" without dash and my patched sshd worked as they
should. Of course, I had no source for "su"... Half an hour and several
new debug_printf's later I suddenly realized, that "su -" completely
replaces the environment, even the CYGWIN variable. That means, after
switching the context suddenly the "ntsec" setting disappeared so that
half of the authentication code in `internal_getlogin' was skipped...

Have fun,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Developer                                mailto:cygwin AT cygwin DOT com
Red Hat, Inc.