current state of credential hopping?

current state of credential hopping?

[Richard Troy]

Hi All,

One of the long-time known problems (limitations) with cygwin has been the
lack of the ability to switch user identities, such as is done with the
suid bit, and su utility. I know that as of last April, there was some
talk of using the cygserver as a partial answer (with shared memory as a
possible attack/leak point). I'm wondering about what's happened or is
happening on this point and I've got a few practical questions and
observations that relate.

The primary question is simple, but does not appear to be reflected in the
archive: Is anybody working on cygserver to get this technology
implemented?

I also observe that the sshd seems to be doing something a bit like this -
how is it doing so? If we have an sshd doing something like this, why not
have an su program? In fact, I have been taking advantage of the client
side of ssh to ask a program be run for you on the "remote" system. Yeah,
performance sucks, but then, at least it works! It does make for a crude
'su' program!

A somewhat related observation is that when I use ssh to create a session
on the system, it seems to work just fine HOWEVER, it does not have good
access to disk shares. How might I go about providing my ssh clients who
are a different user than is logged in into windows (or when noone is
logged in!) access to disk shares? These other users, if logged into
windows directly, have privileges for their own disk share access. The
question then is, how can I mount volumes just for them? Do they need
their own drive letters, or will they be private? ...I've read up on
mount, but don't think this solves the problem: Simply accessing mounts
which another user has the credentials for isn't quite right. The
credentials should be based upon the rights of the user who's using
them... That is to say, how/where do I tell it what username and password
to use for the shares accessed? Or, will windows apply the correct
credentials on my behalf? (I guess I could figure that out on my own with
a lot of testing, but it'd be nice to get a straight answer if someone
knows, please.)

Thanks, and happy CYGWINning!

Richard

-- 
Richard Troy, Chief Scientist
Science Tools Corporation
rtroy@ScienceTools.com, 510-567-9957, http://ScienceTools.com/


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: current state of credential hopping?

[Igor Pechtchanski]

On Mon, 13 Jan 2003, Richard Troy wrote:

> Hi All,
>
> One of the long-time known problems (limitations) with cygwin has been the
> lack of the ability to switch user identities, such as is done with the
> suid bit, and su utility. I know that as of last April, there was some
> talk of using the cygserver as a partial answer (with shared memory as a
> possible attack/leak point). I'm wondering about what's happened or is
> happening on this point and I've got a few practical questions and
> observations that relate.
>
> The primary question is simple, but does not appear to be reflected in the
> archive: Is anybody working on cygserver to get this technology
> implemented?
>
> I also observe that the sshd seems to be doing something a bit like this -
> how is it doing so? If we have an sshd doing something like this, why not
> have an su program? In fact, I have been taking advantage of the client
> side of ssh to ask a program be run for you on the "remote" system. Yeah,
> performance sucks, but then, at least it works! It does make for a crude
> 'su' program!
>
> A somewhat related observation is that when I use ssh to create a session
> on the system, it seems to work just fine HOWEVER, it does not have good
> access to disk shares. How might I go about providing my ssh clients who
> are a different user than is logged in into windows (or when noone is
> logged in!) access to disk shares? These other users, if logged into
> windows directly, have privileges for their own disk share access. The
> question then is, how can I mount volumes just for them? Do they need
> their own drive letters, or will they be private? ...I've read up on
> mount, but don't think this solves the problem: Simply accessing mounts
> which another user has the credentials for isn't quite right. The
> credentials should be based upon the rights of the user who's using
> them... That is to say, how/where do I tell it what username and password
> to use for the shares accessed? Or, will windows apply the correct
> credentials on my behalf? (I guess I could figure that out on my own with
> a lot of testing, but it'd be nice to get a straight answer if someone
> knows, please.)
>
> Thanks, and happy CYGWINning!
> Richard

Richard,

There is a fairly detailed discussion of this in the cygwin-developers
list archives for the past couple of months.

If I recall the details correctly, Windows NT security model allows for
switching the effective userid, but requires a special permission which by
default is given only to the LocalSystem user.  Thus, programs like
'login' or 'su' can only work for a user possessing such a permission.

sshd and telnetd (and cygserver) run under the LocalSystem account, so
they are able to switch user context to the authenticated user.  This is
why 'ssh user@localhost' works.  One of the goals of cygserver, by my
recollection, was to provide a service running as LocalSystem accessible
to the cygwin DLL to perform tasks that require root-like permissions.
Since this service would have to be accessible to non-root processes (by
necessity), security would indeed be an issue.

Technically, nothing prevents an administrator on a machine from giving
this permission (called, I *think*, 'Create a token object') to a user
other than LocalSystem, which will then allow that user to run 'login'
successfully.  It is impractical from a security standpoint, however, to
give this permission to all users.

I think the situation is similar with the network shares, and one needs a
token to access them, but these are murky waters, and I don't claim to
fully understand these issues.

I'll only add that there also seems to be a difference between a
password-authenticated user token and a pubkey-authenticated user token,
and then I'll shut up and let experts like Pierre Humblet or Corinna
Vinschen correct my certainly naive interpretation.
	Igor
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_		pechtcha@cs.nyu.edu
ZZZzz /,`.-'`'    -.  ;-;;,_		igor@watson.ibm.com
     |,4-  ) )-,_. ,\ (  `'-'		Igor Pechtchanski
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

Oh, boy, virtual memory! Now I'm gonna make myself a really *big* RAMdisk!
  -- /usr/games/fortune


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: current state of credential hopping?

[Corinna Vinschen]

On Mon, Jan 13, 2003 at 10:16:57PM -0500, Igor Pechtchanski wrote:
> Technically, nothing prevents an administrator on a machine from giving
> this permission (called, I *think*, 'Create a token object') to a user
> other than LocalSystem, which will then allow that user to run 'login'
> successfully.  It is impractical from a security standpoint, however, to
> give this permission to all users.

Giving it even to one single user is a wide open security hole.

Corinna

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

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/