openssh: privilege separation no longer supported on Cygwin?

openssh: privilege separation no longer supported on Cygwin?

[Houder]

Hi,

Privilege separation in sshd defaults to "sandbox" (as far as
I understand, "openssh" has implemented a new mechanism).

... now I remember Corinna writing, that 'sandbox will not be
an option for Cygwin' ... or words to that effect.

Does this mean, that under Cygwin, privilege separation is no
longer possible?

... because, that is, I think, what I am seeing:

  - the userid of child sshd is still 'cyg_server' ...
  - and I get an elevated shell when I login ...

Not what I expected ...

Gr. Henri

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: openssh: privilege separation no longer supported on Cygwin?

[Marco Atzeri]

On 29/05/2017 07:23, Houder wrote:
> Hi,
>
> Privilege separation in sshd defaults to "sandbox" (as far as
> I understand, "openssh" has implemented a new mechanism).
>
> ... now I remember Corinna writing, that 'sandbox will not be
> an option for Cygwin' ... or words to that effect.
>
> Does this mean, that under Cygwin, privilege separation is no
> longer possible?
>
> ... because, that is, I think, what I am seeing:
>
>  - the userid of child sshd is still 'cyg_server' ...
>  - and I get an elevated shell when I login ...
>
> Not what I expected ...
>
> Gr. Henri
>

Hi Houder,
please read the last Announcement

https://sourceware.org/ml/cygwin-announce/2017-03/msg00028.html

* This release deprecates the sshd_config UsePrivilegeSeparation
    option, thereby making privilege separation mandatory. Privilege
    separation has been on by default for almost 15 years and
    sandboxing has been on by default for almost the last five.


It seems you misunderstood the communication:
- the possibility to NOT use "privilege separation" is deprecated
- "privilege separation" will became mandatory

Regards
Marco


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: openssh: privilege separation no longer supported on Cygwin?

[Houder]

On 2017-05-29 10:39, Marco Atzeri wrote:
> On 29/05/2017 07:23, Houder wrote:

[snip]
>> ... because, that is, I think, what I am seeing:
>> 
>>  - the userid of child sshd is still 'cyg_server' ...
>>  - and I get an elevated shell when I login ...
>> 
>> Not what I expected ...
>> 
>> Gr. Henri
>> 
> 
> Hi Houder,
> please read the last Announcement
> 
> https://sourceware.org/ml/cygwin-announce/2017-03/msg00028.html

[snip]
> It seems you misunderstood the communication:
> - the possibility to NOT use "privilege separation" is deprecated
> - "privilege separation" will became mandatory

Hi Marco,

Sorry for the misunderstanding. Yes, to my knowledge, PS, privilege
separation, is now mandatory (using a new mechanism under Linux [1]).

[1] sandboxing?

Because of PS, I expect to see an UNprivileged sshd process talking
to the user process (where the ssh command has been executed).

But above all, I expect an UNelevated shell when I login in ...

However, what I get after login (after providing my credentials) is
an ELEVATED shell (yes, Administrators is part of the group set).

Now I wonder if this happens because I do NOT observe PS.

Look below, please ... After executing the ssh command, ssh asks for
my credentials ... in stead of providing my credentials, I execute
the ps command in a second terminal. To my surprise, the grandchild
of the listener is executed using "cyg_server" and not "sshd" ...

Currently, I am looking at:

     https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-setuid-overview

Regards,
Henri

-----
  - pre-authentication:

Shell 1:
64-@@ ssh -p 222 -l Henri 192.168.178.15
Enter passphrase for key '/home/Henri/.ssh/id_rsa': <==== passphrase not 
yet entered

Shell 2: (observer)
64-@@# ps -af
      UID     PID    PPID  TTY        STIME COMMAND
    Henri    2308    4356 pty0     11:01:41 /usr/bin/ssh
    Henri    5092     176 pty1     11:01:58 /usr/bin/ps
    Henri    4356    3744 pty0     10:57:56 /usr/bin/bash
    Henri    3744       1 ?        10:57:50 /usr/bin/mintty-273
    Henri     176    4604 pty1     10:58:21 /usr/bin/bash
cyg_serv    4992    2476 ?        11:01:03 /usr/sbin/sshd               
privileged listener
cyg_serv    2476       1 ?        11:01:03 /usr/bin/cygrunsrv
    Henri    4604       1 ?        10:58:21 /usr/bin/mintty-273
cyg_serv    1496    3032 ?        11:01:42 /usr/sbin/sshd               
should be using sshd as userid
cyg_serv    3032    4992 ?        11:01:42 /usr/sbin/sshd               
privileged monitor (child of listener)

  - post-authentication:

Shell 1:
64-@@ ssh -p 222 -l Henri 192.168.178.15
Enter passphrase for key '/home/Henri/.ssh/id_rsa': <==== passphrase has 
been entered
Last login: Mon May 29 10:07:00 2017 from 192.168.178.15
64-@@#  <===== ///// PROBLEM: this shell is ELEVATED /////

Shell 2: (observer)
64-@@# ps -af
      UID     PID    PPID  TTY        STIME COMMAND
    Henri    2496    3032 pty3     11:02:31 /usr/bin/bash                
remote shell (but it is an elevated shell! ?????)
    Henri    2308    4356 pty0     11:01:41 /usr/bin/ssh
    Henri    4356    3744 pty0     10:57:56 /usr/bin/bash
    Henri    3744       1 ?        10:57:50 /usr/bin/mintty-273
    Henri     176    4604 pty1     10:58:21 /usr/bin/bash
cyg_serv    4992    2476 ?        11:01:03 /usr/sbin/sshd               
privileged listener
    Henri    4996     176 pty1     11:06:05 /usr/bin/ps
cyg_serv    2476       1 ?        11:01:03 /usr/bin/cygrunsrv
    Henri    4604       1 ?        10:58:21 /usr/bin/mintty-273
cyg_serv    3032    4992 ?        11:01:42 /usr/sbin/sshd               
privileged monitor (child of listener)

=====

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: openssh: privilege separation no longer supported on Cygwin? -- example only

[Houder]

On 2017-05-29 11:48, Houder wrote:

  - pre-authentication:

Shell 1:
64-@@ ssh -p 222 -l Henri 192.168.178.15
Enter passphrase for key '/home/Henri/.ssh/id_rsa': <==== passphrase not 
yet entered

Shell 2: (observer)
64-@@# ps -af
      UID     PID    PPID  TTY        STIME COMMAND
    Henri    2308    4356 pty0     11:01:41 /usr/bin/ssh
    Henri    5092     176 pty1     11:01:58 /usr/bin/ps
    Henri    4356    3744 pty0     10:57:56 /usr/bin/bash
    Henri    3744       1 ?        10:57:50 /usr/bin/mintty-273
    Henri     176    4604 pty1     10:58:21 /usr/bin/bash
cyg_serv    4992    2476 ?        11:01:03 /usr/sbin/sshd               
privileged listener
cyg_serv    2476       1 ?        11:01:03 /usr/bin/cygrunsrv
    Henri    4604       1 ?        10:58:21 /usr/bin/mintty-273
cyg_serv    1496    3032 ?        11:01:42 /usr/sbin/sshd               
should be using sshd as userid
cyg_serv    3032    4992 ?        11:01:42 /usr/sbin/sshd               
privileged monitor (child of listener)

  - post-authentication:

Shell 1:
64-@@ ssh -p 222 -l Henri 192.168.178.15
Enter passphrase for key '/home/Henri/.ssh/id_rsa': <==== passphrase has 
been entered
Last login: Mon May 29 10:07:00 2017 from 192.168.178.15
64-@@#  <===== ///// PROBLEM: this shell is ELEVATED /////

Shell 2: (observer)
64-@@# ps -af
      UID     PID    PPID  TTY        STIME COMMAND
    Henri    2496    3032 pty3     11:02:31 /usr/bin/bash               
remote shell (but it is an elevated shell! ?????)
    Henri    2308    4356 pty0     11:01:41 /usr/bin/ssh
    Henri    4356    3744 pty0     10:57:56 /usr/bin/bash
    Henri    3744       1 ?        10:57:50 /usr/bin/mintty-273
    Henri     176    4604 pty1     10:58:21 /usr/bin/bash
cyg_serv    4992    2476 ?        11:01:03 /usr/sbin/sshd              
privileged listener
    Henri    4996     176 pty1     11:06:05 /usr/bin/ps
cyg_serv    2476       1 ?        11:01:03 /usr/bin/cygrunsrv
    Henri    4604       1 ?        10:58:21 /usr/bin/mintty-273
cyg_serv    3032    4992 ?        11:01:42 /usr/sbin/sshd              
privileged monitor (child of listener)

======

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: openssh: privilege separation no longer supported on Cygwin?

[Houder]

On 2017-05-29 11:48, Houder wrote:

The following might help help clarify "my words" in my previous
post ... (pictures!)

     
https://security.stackexchange.com/questions/115896/can-someone-explain-how-sshd-does-privilege-separation

     http://www.citi.umich.edu/u/provos/ssh/privsep.html

     http://www.citi.umich.edu/u/provos/papers/privsep.pdf
     (Niels Provos, Markus Friedl and Peter Honeyman, 12th USENIX
      Security Symposium, Washington, DC, August 2003)

Regards,

Henri

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: openssh: privilege separation no longer supported on Cygwin? SURPRISE!

[Houder]

On 2017-05-29 11:48, Houder wrote:
> On 2017-05-29 10:39, Marco Atzeri wrote:
>> On 29/05/2017 07:23, Houder wrote:
> 
> [snip]
>>> ... because, that is, I think, what I am seeing:
>>> 
>>>  - the userid of child sshd is still 'cyg_server' ...
>>>  - and I get an elevated shell when I login ...
>>> 
>>> Not what I expected ...
>>> 
>>> Gr. Henri
>>> 
>> 
>> Hi Houder,
>> please read the last Announcement
>> 
>> https://sourceware.org/ml/cygwin-announce/2017-03/msg00028.html
> 
> [snip]
>> It seems you misunderstood the communication:
>> - the possibility to NOT use "privilege separation" is deprecated
>> - "privilege separation" will became mandatory
> 
> Hi Marco,
> 
> Sorry for the misunderstanding. Yes, to my knowledge, PS, privilege
> separation, is now mandatory (using a new mechanism under Linux [1]).
> 
> [1] sandboxing?
> 
> Because of PS, I expect to see an UNprivileged sshd process talking
> to the user process (where the ssh command has been executed).
> 
> But above all, I expect an UNelevated shell when I login in ...
> 
> However, what I get after login (after providing my credentials) is
> an ELEVATED shell (yes, Administrators is part of the group set).
> 
> Now I wonder if this happens because I do NOT observe PS.
> 
> Look below, please ... After executing the ssh command, ssh asks for
> my credentials ... in stead of providing my credentials, I execute
> the ps command in a second terminal. To my surprise, the grandchild
> of the listener is executed using "cyg_server" and not "sshd" ...
> 
> Currently, I am looking at:
> 
>     https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-setuid-overview

... and read it MULTIPLE times! (and tried, well, about anything)

However, I found a clue here:

     https://sourceware.org/ml/cygwin/2011-10/msg00035.html
     (Re: admin privileges when logging in by ssh? -- by Corinna)

The thread starts here:

     https://cygwin.com/ml/cygwin/2011-09/msg00138.html
     (admin privileges when logging in by ssh? -- by Andrew Schulman)

Above Corinna writes:

"In all cases, password auth and passwordless auth, you should get a 
full
admin token.  In case of password auth and in the passwordless methods
2 and 3, the OS returns a restricted token under UAC, but ...

     that token has a _reference_ to the full admin token attached. 
Cygwin
     fetches this token and uses that when switching the user context.
     =================================================================

Oh? Ah!

The account (Henri) from which I executed the ssh command, is - yes, I
forgot to tell - , a privileged account ...

However when I login to that account, it "normally" starts an UNelevated
shell ... Not so if one executes the ssh command ... apparently.

     And that is a bit of a SURPRISE ... to say the least !!!!!

Even more surprising is when I execute the ssh command from an account
that is NOT privileged (using another account, named jvdwater).

  - yes. this time I get an UNelevated shell (using ssh)
  - however, the userid of the grandchild of the sshd listener, is STILL
    cyg_server ... NOT sshd!

As if the "sshd" account is NEVER, NEVER used during the _whole_ process
(that is, there is NO privilege separation, as far as I can tell).

Regards,

Henri

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: openssh: privilege separation no longer supported on Cygwin? SURPRISE!

[Andrey Repin]

Greetings, Houder!

>   - however, the userid of the grandchild of the sshd listener, is STILL
>     cyg_server ... NOT sshd!

Exactly. cyg_server is the user which does impersonation.
You've been told that when you've been setting up your host.

> As if the "sshd" account is NEVER, NEVER used during the _whole_ process
> (that is, there is NO privilege separation, as far as I can tell).

As far as it is documented.


-- 
With best regards,
Andrey Repin
Monday, May 29, 2017 22:56:04

Sorry for my terrible english...


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: openssh: privilege separation no longer supported on Cygwin? SURPRISE!

[Houder]

On 2017-05-29 21:57, Andrey Repin wrote:
> Greetings, Houder!
> 
>>   - however, the userid of the grandchild of the sshd listener, is 
>> STILL
>>     cyg_server ... NOT sshd!
> 
> Exactly. cyg_server is the user which does impersonation.
> You've been told that when you've been setting up your host.

     http://www.citi.umich.edu/u/provos/ssh/privsep.html

     
https://security.stackexchange.com/questions/115896/can-someone-explain-how-sshd-does-privilege-separation

     https://cygwin.com/ml/cygwin/2017-05/msg00468.html

>> As if the "sshd" account is NEVER, NEVER used during the _whole_ 
>> process
>> (that is, there is NO privilege separation, as far as I can tell).
> 
> As far as it is documented.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: openssh: privilege separation no longer supported on Cygwin? SURPRISE!

[Houder]

On Mon, 29 May 2017 19:14:30, Houder wrote:

[snip]
> As if the "sshd" account is NEVER, NEVER used during the _whole_ process
> (that is, there is NO privilege separation, as far as I can tell).

.. wanted to share this experience with you.

 - deleted user/account 'sshd' # net user sshd /delete
 - modified the last part (rid?) of the sid belonging to user/account 'sshd'
   in xxxx (in /etc/passwd)
 - rebooted

Before reboot, I changed 'sshd' in an automatic service (was: manual)

After the system had rebooted:

 - 'cygrunsrv -Q sshd' shows 'sshd' running ...
 - 'tail -f /var/log/sshd.log' shows 'sshd' listening ...
 - 'net user' shows user/account 'sshd' gone ...

I can still use ssh ... (both password authentication and key authentication)

Yes, if I remove user/account 'sshd' completely from /etc/passwd, only
then 'sshd' won't start ...

Regards,

Henri

=====


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: openssh: privilege separation no longer supported on Cygwin? SURPRISE!

[Larry Hall (Cygwin)]

On 05/30/2017 09:50 AM, Houder wrote:
> On Mon, 29 May 2017 19:14:30, Houder wrote:
>
> [snip]
>> As if the "sshd" account is NEVER, NEVER used during the _whole_ process
>> (that is, there is NO privilege separation, as far as I can tell).
>
> .. wanted to share this experience with you.
>
>   - deleted user/account 'sshd' # net user sshd /delete
>   - modified the last part (rid?) of the sid belonging to user/account 'sshd'
>     in xxxx (in /etc/passwd)
>   - rebooted
>
> Before reboot, I changed 'sshd' in an automatic service (was: manual)
>
> After the system had rebooted:
>
>   - 'cygrunsrv -Q sshd' shows 'sshd' running ...
>   - 'tail -f /var/log/sshd.log' shows 'sshd' listening ...
>   - 'net user' shows user/account 'sshd' gone ...
>
> I can still use ssh ... (both password authentication and key authentication)
>
> Yes, if I remove user/account 'sshd' completely from /etc/passwd, only
> then 'sshd' won't start ...

Cygwin's link to the Windows user ID is through the UID/SID mapping.  In
your case, you're apparently using /etc/passwd and so that's where the
mapping happens.  You can map the UID of a Cygwin user to any valid Windows
SID by editing the SID as you did.  This doesn't change how things look in
the Cygwin environment (i.e. the UID and user name are still the same) but
it does make a difference to Windows.  So the fact that you can change the
SID for the 'sshd' user and still get it to run is not all that surprising,
assuming that the new Windows SID that you're using as 'sshd' now has at
least similar permissions.  Of course, if you remove Cygwin's understanding
of 'sshd' so that it can't do the mapping of UID to SID or even have a
valid UID, then subsequent problems are not unexpected.


-- 
Larry

_____________________________________________________________________

A: Yes.
 > Q: Are you sure?
 >> A: Because it reverses the logical flow of conversation.
 >>> Q: Why is top posting annoying in email?

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: openssh: privilege separation no longer supported on Cygwin? SURPRISE!

[Houder]

On Tue, 30 May 2017 21:28:41, "Larry Hall (Cygwin)" wrote:

[snip]
> Cygwin's link to the Windows user ID is through the UID/SID mapping.  In
> your case, you're apparently using /etc/passwd and so that's where the
> mapping happens.  You can map the UID of a Cygwin user to any valid Windows
> SID by editing the SID as you did.  This doesn't change how things look in
> the Cygwin environment (i.e. the UID and user name are still the same) but
> it does make a difference to Windows.  So the fact that you can change the
> SID for the 'sshd' user and still get it to run is not all that surprising,
> assuming that the new Windows SID that you're using as 'sshd' now has at
> least similar permissions.  Of course, if you remove Cygwin's understanding
> of 'sshd' so that it can't do the mapping of UID to SID or even have a
> valid UID, then subsequent problems are not unexpected.

Hi Larry,

Thanks for your reply! Discussion!

First of all, I do not pretend to know Windows ... neither do I pretend that I
know more about ssh/Cygwin than Corinna does (basically, I know not very much).

.. the only thing I am able to, is "observe" (and I may interpret wrong), and
may have done "stupid" things. That is why your reply is appreciated by me.

Now back to your reply:

I had modified /etc/password as follows: (note the xxxx in the sid)

sshd:*:1015:513:U-Seven\sshd,S-1-5-21-91509220-1575020443-2714799223-xxxx:/var/empty:/bin/false

However, just now I modified it as follows:

sshd:*:1015:513:U-Seven\sshd,S-1-5-21-xxxxxxxx-xxxxxxxxxx-xxxxxxxxxx-xxxx:/var/empty:/bin/false

(again changed the sshd service into 'automatic'), and rebooted the system.

After system reboot, an elevated shell is started ...
(the ampersand sign at the end of the prompt indicates it is an elevated shell)

# my .bash_profile interrogates the cygwin1.dll ...
/home/corinna/src/cygwin/cygwin-2.8.0/cygwin-2.8.0-1.x86_64/src/newlib-cygwin/winsup/cygwin/cygheap.cc
64-@@# 
64-@@# cygrunsrv -Q sshd
Service             : sshd
Display name        : CYGWIN sshd
Current State       : Running
Controls Accepted   : Stop
Command             : /usr/sbin/sshd -4 -D -e

Looking good ...

64-@@# net user sshd
The user name could not be found.

More help is available by typing NET HELPMSG 2221.

As far as I know, this means that Windows tells me user sshd does NOT exist!

However, I can still use the ssh command ... (see below).

Now, if I understand correctly, "Corinna" may use the first (of the 4) method,
i.e. the one based on NtCreateToken(), to change the user context ...
(Q: is that even possible for a NON-existing user?)

However, neither the ps command nor the "Process Explorer" show me a context
that "belongs" to user sshd [1] (in stead it belongs to user cyg_server).

[1] I refer to the grandchild of the listener, the one that exists before the
authentication phase terminates ...

Yes, I know; I may still be wrong ... I report what I observe ... yes, I do
not have the deep knowledge of Windows that Corinna has. I know.

Regards,

Henri

-----
From an UNelevated shell:

64-@@ ssh -p <SOME-PORT> -l Henri 192.168.178.15
Enter passphrase for key '/home/Henri/.ssh/<SOME-KEY>': # Henri is privileged
Last login: Wed May 31 10:30:52 2017 from 192.168.178.15
TADA !!!!! <==== contents of /etc/motd
/home/corinna/src/cygwin/cygwin-2.8.0/cygwin-2.8.0-1.x86_64/src/newlib-cygwin/winsup/cygwin/cygheap.cc
64-@@# exit <==== full-blown elevated shell! (try whoami /all)
logout
Connection to 192.168.178.15 closed.

64-@@ ssh -p <SOME-PORT> -l jvdwater 192.168.178.15
jvdwater@192.168.178.15's password: # jvdwater is UNprivileged
Last login: Wed May 31 10:29:27 2017 from 192.168.178.15
TADA !!!!!
64-@@ exit <==== ordinary UNelevated shell
logout
Connection to 192.168.178.15 closed.

64-@@# tail -f /var/log/sshd.log
Server listening on 0.0.0.0 port <SOME-PORT>.
Accepted publickey for Henri from 192.168.178.15 port 49186 ssh2: <SOME-KEY>
Received disconnect from 192.168.178.15 port 49186:11: disconnected by user
Disconnected from user Henri 192.168.178.15 port 49186
Accepted password for jvdwater from 192.168.178.15 port 49191 ssh2
Received disconnect from 192.168.178.15 port 49191:11: disconnected by user
Disconnected from user jvdwater 192.168.178.15 port 49191

=====


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: openssh: privilege separation no longer supported on Cygwin? SURPRISE!

[cyg Simple]

On 5/31/2017 5:37 AM, Houder wrote:
> On Tue, 30 May 2017 21:28:41, "Larry Hall (Cygwin)" wrote:
> 
> [snip]
>> Cygwin's link to the Windows user ID is through the UID/SID mapping.  In
>> your case, you're apparently using /etc/passwd and so that's where the
>> mapping happens.  You can map the UID of a Cygwin user to any valid Windows
>> SID by editing the SID as you did.  This doesn't change how things look in
>> the Cygwin environment (i.e. the UID and user name are still the same) but
>> it does make a difference to Windows.  So the fact that you can change the
>> SID for the 'sshd' user and still get it to run is not all that surprising,
>> assuming that the new Windows SID that you're using as 'sshd' now has at
>> least similar permissions.  Of course, if you remove Cygwin's understanding
>> of 'sshd' so that it can't do the mapping of UID to SID or even have a
>> valid UID, then subsequent problems are not unexpected.
> 
> Hi Larry,
> 
> Thanks for your reply! Discussion!
> 
> First of all, I do not pretend to know Windows ... neither do I pretend that I
> know more about ssh/Cygwin than Corinna does (basically, I know not very much).
> 
> .. the only thing I am able to, is "observe" (and I may interpret wrong), and
> may have done "stupid" things. That is why your reply is appreciated by me.
> 
> Now back to your reply:
> 
> I had modified /etc/password as follows: (note the xxxx in the sid)
> 
> sshd:*:1015:513:U-Seven\sshd,S-1-5-21-91509220-1575020443-2714799223-xxxx:/var/empty:/bin/false
> 
> However, just now I modified it as follows:
> 
> sshd:*:1015:513:U-Seven\sshd,S-1-5-21-xxxxxxxx-xxxxxxxxxx-xxxxxxxxxx-xxxx:/var/empty:/bin/false
> 
> (again changed the sshd service into 'automatic'), and rebooted the system.
> 
> After system reboot, an elevated shell is started ...
> (the ampersand sign at the end of the prompt indicates it is an elevated shell)

All of this talk of /etc/passwd leads me to point you to
https://cygwin.com/cygwin-ug-net/ntsec.html.

-- 
cyg Simple

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: openssh: privilege separation no longer supported on Cygwin? SURPRISE!

[Houder]

On Wed, 31 May 2017 09:27:02, cyg Simple wrote:

[snip]
> All of this talk of /etc/passwd leads me to point you to
> https://cygwin.com/cygwin-ug-net/ntsec.html.

cyg,

Do you want me to study that text a second, third, fourth or Xth time ...?

However, let me take another angle now ...

Active Directory is just Microsoft's version of the 'network database', a way
to keep housekeeping in a centralized manner (like NIS).

Agreed?

Anyone out there, who uses AD, in stead of /etc/{passwd,group}, and observes
that the grandchild of the listener is executed by user "sshd"?

Anyone out there, who uses AD, in stead of /etc/{passwd,group}, and is brave
enough to delete the sshd account? Is ssh still working?

Now you might say that I am "a bit aggressive" above (yes, I _do_ feel a bit
peevish). However I would like to see arguments that stick and/or proof that
shows me wrong.

Larry Hall replied with an argument, you did not (neither did Andrey Repin).

Regards,

Henri


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: openssh: privilege separation no longer supported on Cygwin? SURPRISE! -- minor correction

[Houder]

On Wed, 31 May 2017 16:16:38, Houder wrote:

[snip]
> Anyone out there, who uses AD, in stead of /etc/{passwd,group}, and is brave
> enough to delete the sshd account? Is ssh still working?

i.e. NOT from AD, but delete as an account (net user sshd /delete).

Regards,

Henri


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: openssh: privilege separation no longer supported on Cygwin? SURPRISE!

[cyg Simple]

On 5/31/2017 10:16 AM, Houder wrote:
> On Wed, 31 May 2017 09:27:02, cyg Simple wrote:
> 
> [snip]
>> All of this talk of /etc/passwd leads me to point you to
>> https://cygwin.com/cygwin-ug-net/ntsec.html.
> 
> cyg,
> 
> Do you want me to study that text a second, third, fourth or Xth time ...?
> 

Yes, especially section
https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-mapping where it
explains that /etc/passwd and /etc/group are now deprecated and it's use
is for backward compatibility and that you should be using
/etc/nsswitch.conf[1] instead.  Have you attempted this?

[1] https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-mapping-nsswitch

-- 
cyg Simple

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: openssh: privilege separation no longer supported on Cygwin? SURPRISE!

[Houder]

On Wed, 31 May 2017 10:59:38, cyg Simple wrote:
> On 5/31/2017 10:16 AM, Houder wrote:
> > On Wed, 31 May 2017 09:27:02, cyg Simple wrote:
> > 
> > [snip]
> >> All of this talk of /etc/passwd leads me to point you to
> >> https://cygwin.com/cygwin-ug-net/ntsec.html.
> > 
> > cyg,
> > 
> > Do you want me to study that text a second, third, fourth or Xth time ...?
> > 
> 
> Yes, especially section
> https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-mapping where it
> explains that /etc/passwd and /etc/group are now deprecated and it's use
> is for backward compatibility and that you should be using
> /etc/nsswitch.conf[1] instead.  Have you attempted this?
> 
> [1] https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-mapping-nsswitch

Actually, that text reads:

 = Mapping Windows SIDs to POSIX uid/gid values:

  * Read /etc/passwd and /etc/group files if they exist, just as in the olden
    days, mainly for backward compatibility.
-----

It does not stipulate that these files are no longer supported ... Corinna did
not dare to proclaim them "deprecated".

Do I use the file /etc/nsswitch.conf? Yes, certainly. As shown in:

    https://cygwin.com/ml/cygwin/2017-05/msg00456.html
    (see bottom of post)

Do you want me to drop /etc/{passwd,group} files. Yes, you do. I will not.

Moreover, it is completely irrelevant from a logical point of view  whether
/etc/{passwd,group) or AD is used to maintain the "network administration".

Regards,

Henri


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: openssh: privilege separation no longer supported on Cygwin? SURPRISE!

[cyg Simple]

On 5/31/2017 12:34 PM, Houder wrote:
> On Wed, 31 May 2017 10:59:38, cyg Simple wrote:
>> On 5/31/2017 10:16 AM, Houder wrote:
>>> On Wed, 31 May 2017 09:27:02, cyg Simple wrote:
>>>
>>> [snip]
>>>> All of this talk of /etc/passwd leads me to point you to
>>>> https://cygwin.com/cygwin-ug-net/ntsec.html.
>>>
>>> cyg,
>>>
>>> Do you want me to study that text a second, third, fourth or Xth time ...?
>>>
>>
>> Yes, especially section
>> https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-mapping where it
>> explains that /etc/passwd and /etc/group are now deprecated and it's use
>> is for backward compatibility and that you should be using
>> /etc/nsswitch.conf[1] instead.  Have you attempted this?
>>
>> [1] https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-mapping-nsswitch
> 
> Actually, that text reads:
> 
>  = Mapping Windows SIDs to POSIX uid/gid values:
> 
>   * Read /etc/passwd and /etc/group files if they exist, just as in the olden
>     days, mainly for backward compatibility.
> -----
> 
> It does not stipulate that these files are no longer supported ... Corinna did
> not dare to proclaim them "deprecated".
> 
> Do I use the file /etc/nsswitch.conf? Yes, certainly. As shown in:
> 
>     https://cygwin.com/ml/cygwin/2017-05/msg00456.html
>     (see bottom of post)
> 
> Do you want me to drop /etc/{passwd,group} files. Yes, you do. I will not.
> 

That choice is yours but they are needless except for very limited needs.

> Moreover, it is completely irrelevant from a logical point of view  whether
> /etc/{passwd,group) or AD is used to maintain the "network administration".
> 

So what.  You have to maintain separate multiple databases for the same
user.

Just give removing these two files a try to see if you have good success.

-- 
cyg Simple

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: openssh: privilege separation no longer supported on Cygwin?

[Marco Atzeri]

On 29/05/2017 11:48, Houder wrote:
> On 2017-05-29 10:39, Marco Atzeri wrote:
>> On 29/05/2017 07:23, Houder wrote:
>
> [snip]
>>> ... because, that is, I think, what I am seeing:
>>>
>>>  - the userid of child sshd is still 'cyg_server' ...
>>>  - and I get an elevated shell when I login ...
>>>
>>> Not what I expected ...
>>>
>>> Gr. Henri
>>>
>>
>> Hi Houder,
>> please read the last Announcement
>>
>> https://sourceware.org/ml/cygwin-announce/2017-03/msg00028.html
>
> [snip]
>> It seems you misunderstood the communication:
>> - the possibility to NOT use "privilege separation" is deprecated
>> - "privilege separation" will became mandatory
>
> Hi Marco,
>
> Sorry for the misunderstanding. Yes, to my knowledge, PS, privilege
> separation, is now mandatory (using a new mechanism under Linux [1]).
>
> [1] sandboxing?
>
> Because of PS, I expect to see an UNprivileged sshd process talking
> to the user process (where the ssh command has been executed).
>
> But above all, I expect an UNelevated shell when I login in ...
>
> However, what I get after login (after providing my credentials) is
> an ELEVATED shell (yes, Administrators is part of the group set).

Is your user a member of Administrators ?

>
> Now I wonder if this happens because I do NOT observe PS.
>
> Look below, please ... After executing the ssh command, ssh asks for
> my credentials ... in stead of providing my credentials, I execute
> the ps command in a second terminal. To my surprise, the grandchild
> of the listener is executed using "cyg_server" and not "sshd" ...
>
> Currently, I am looking at:
>
>     https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-setuid-overview
>
> Regards,
> Henri
>

on my system as reported by lusrmgr.msc
cyg_server is a privileged user member of Administrators
sshd is a normal user as expected reading ssh-host-config.

The cyg_server account can setuid to other users
otherwise you can not change user id:

$ pstree -u
?─┬─cygrunsrv(cyg_server)───sshd───sshd───bash(marco)───pstree
   ├─mintty(marco)───bash───ssh
   └─mintty(marco)───bash

Regards
Marco






--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: openssh: privilege separation no longer supported on Cygwin? SURPRISE!

[Larry Hall (Cygwin)]

On 05/31/2017 05:37 AM, Houder wrote:
> On Tue, 30 May 2017 21:28:41, "Larry Hall (Cygwin)" wrote:
>
> [snip]
>> Cygwin's link to the Windows user ID is through the UID/SID mapping.  In
>> your case, you're apparently using /etc/passwd and so that's where the
>> mapping happens.  You can map the UID of a Cygwin user to any valid Windows
>> SID by editing the SID as you did.  This doesn't change how things look in
>> the Cygwin environment (i.e. the UID and user name are still the same) but
>> it does make a difference to Windows.  So the fact that you can change the
>> SID for the 'sshd' user and still get it to run is not all that surprising,
>> assuming that the new Windows SID that you're using as 'sshd' now has at
>> least similar permissions.  Of course, if you remove Cygwin's understanding
>> of 'sshd' so that it can't do the mapping of UID to SID or even have a
>> valid UID, then subsequent problems are not unexpected.
>
> Hi Larry,
>
> Thanks for your reply! Discussion!
>
> First of all, I do not pretend to know Windows ... neither do I pretend that I
> know more about ssh/Cygwin than Corinna does (basically, I know not very much).
>
> .. the only thing I am able to, is "observe" (and I may interpret wrong), and
> may have done "stupid" things. That is why your reply is appreciated by me.
>
> Now back to your reply:
>
> I had modified /etc/password as follows: (note the xxxx in the sid)
>
> sshd:*:1015:513:U-Seven\sshd,S-1-5-21-91509220-1575020443-2714799223-xxxx:/var/empty:/bin/false
>
> However, just now I modified it as follows:
>
> sshd:*:1015:513:U-Seven\sshd,S-1-5-21-xxxxxxxx-xxxxxxxxxx-xxxxxxxxxx-xxxx:/var/empty:/bin/false
>
> (again changed the sshd service into 'automatic'), and rebooted the system.
>
> After system reboot, an elevated shell is started ...
> (the ampersand sign at the end of the prompt indicates it is an elevated shell)
>
> # my .bash_profile interrogates the cygwin1.dll ...
> /home/corinna/src/cygwin/cygwin-2.8.0/cygwin-2.8.0-1.x86_64/src/newlib-cygwin/winsup/cygwin/cygheap.cc
> 64-@@#
> 64-@@# cygrunsrv -Q sshd
> Service             : sshd
> Display name        : CYGWIN sshd
> Current State       : Running
> Controls Accepted   : Stop
> Command             : /usr/sbin/sshd -4 -D -e
>
> Looking good ...
>
> 64-@@# net user sshd
> The user name could not be found.
>
> More help is available by typing NET HELPMSG 2221.
>
> As far as I know, this means that Windows tells me user sshd does NOT exist!
>
> However, I can still use the ssh command ... (see below).
>
> Now, if I understand correctly, "Corinna" may use the first (of the 4) method,
> i.e. the one based on NtCreateToken(), to change the user context ...
> (Q: is that even possible for a NON-existing user?)
>
> However, neither the ps command nor the "Process Explorer" show me a context
> that "belongs" to user sshd [1] (in stead it belongs to user cyg_server).
>
> [1] I refer to the grandchild of the listener, the one that exists before the
> authentication phase terminates ...
>
> Yes, I know; I may still be wrong ... I report what I observe ... yes, I do
> not have the deep knowledge of Windows that Corinna has. I know.
>
> Regards,
>
> Henri
>
> -----
>From an UNelevated shell:
>
> 64-@@ ssh -p <SOME-PORT> -l Henri 192.168.178.15
> Enter passphrase for key '/home/Henri/.ssh/<SOME-KEY>': # Henri is privileged
> Last login: Wed May 31 10:30:52 2017 from 192.168.178.15
> TADA !!!!! <==== contents of /etc/motd
> /home/corinna/src/cygwin/cygwin-2.8.0/cygwin-2.8.0-1.x86_64/src/newlib-cygwin/winsup/cygwin/cygheap.cc
> 64-@@# exit <==== full-blown elevated shell! (try whoami /all)
> logout
> Connection to 192.168.178.15 closed.
>
> 64-@@ ssh -p <SOME-PORT> -l jvdwater 192.168.178.15
> jvdwater@192.168.178.15's password: # jvdwater is UNprivileged
> Last login: Wed May 31 10:29:27 2017 from 192.168.178.15
> TADA !!!!!
> 64-@@ exit <==== ordinary UNelevated shell
> logout
> Connection to 192.168.178.15 closed.
>
> 64-@@# tail -f /var/log/sshd.log
> Server listening on 0.0.0.0 port <SOME-PORT>.
> Accepted publickey for Henri from 192.168.178.15 port 49186 ssh2: <SOME-KEY>
> Received disconnect from 192.168.178.15 port 49186:11: disconnected by user
> Disconnected from user Henri 192.168.178.15 port 49186
> Accepted password for jvdwater from 192.168.178.15 port 49191 ssh2
> Received disconnect from 192.168.178.15 port 49191:11: disconnected by user
> Disconnected from user jvdwater 192.168.178.15 port 49191

I'm replying directly to your original replies to me but this
shouldn't indicate to anyone that subsequent discussion by others hasn't
provided good and useful information.  My reply more directly addresses
your email though so I wanted to reference it without those intervening
discussions to hopefully avoid confusion.

At the moment, the only system I have access to that has Cygwin's SSH set
up on it is one that's using AD and there when I login using public key or
password authentication, I'm always logged in as my user without elevated
privileges.  I'm not going to speculate about whether this is indicative of
proper operation or not for this environment.  I just offer it as another
observation.  That said, I will offer one speculation (because I haven't
tested this in all environments) and one additional observation.  If your
login does contain the full admin token, I could envision a benefit to
using that token when logging in, even if it seems a little counter-
intuitive (i.e. different than similar Windows usage scenarios).  There
currently isn't a mechanism to elevate your privileges from the command
line using any Cygwin utility.  But there is a utility to drop privileges. 
It's called 'cygdrop' and it's part of the 'cygutil-extras" package.  Using
this, it is possible to remove any tokens you wish to drop.  So in the
scenario I postulated above, this would give you access to both possible
states but only if you start in an elevated state.

Lastly, I just want to point out that you seem to be confusing the
fact that you're telling Cygwin to use 'sshd' as the name it should assign
to a particular UID/SID mapping while there is no Windows user named 'sshd'.
Names assigned to UIDs in Cygwin do not need to match the name of the
associated SID in Windows.  These concepts are completely orthogonal.
Indeed, this can be used to do very useful things, like aliasing a Windows
name containing spaces or other undesirable characters to a Cygwin user
name that doesn't have these troublesome aspects.  So aliasing any SID to
a Cygwin user name/UID is a valid thing to do and should work just as well
as matching the name to the one the SID uses.  I will also point out that
deleting a user in Windows does not invalidate the SID that was associated
with it.  It simply makes it far less accessible.  But because there could
be files on the filesystem that still reference this SID, it needs to
remain valid otherwise the filesystem would become unstable when users are
deleted.  This last point isn't that significant in the scenario you've
mapped out but I mention it to hopefully help clarify the differences
between user names and SIDs in Windows.

-- 
Larry

_____________________________________________________________________

A: Yes.
 > Q: Are you sure?
 >> A: Because it reverses the logical flow of conversation.
 >>> Q: Why is top posting annoying in email?

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple