X-Recipient:	archive-cygwin AT delorie DOT com
DomainKey-Signature:	a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:mime-version:content-type
	:content-transfer-encoding:date:from:to:subject:in-reply-to
	:references:message-id; q=dns; s=default; b=cN2aENVopL0bJOpa34xi
	25p3aA022z8k+LPllh/RcyE/VE+uTDoC+JH1SnO99XaupOGRS0IPvgqnFDorkAEU
	DA9cp5jFGZ5LYib6GSc/5LKABrTYiAKIwVRaIVHQif0++ilw/COW//e7mPyQCuiM
	L3Pe/u8c7x+kJhMUrTVQpuY=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:mime-version:content-type
	:content-transfer-encoding:date:from:to:subject:in-reply-to
	:references:message-id; s=default; bh=JGiZMlpttAXbiYzv7nMKDi1z2M
	Q=; b=sOkztpTr1JjxI4pLX6ioYbUivQRjsgjc77C5dFOIe7V6sDzx4to6p4xiEr
	Q/y2MTjVdyZ7j+SANxVMIyEgXxFKVfTutmKoumIPu2qkDdL2alP80bzK7CYo+AMh
	YB3Mca21dZSFHZ5tlzDCFjuNaGXF1xBxpq8iypYPByFVrwRtU=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
Authentication-Results:	sourceware.org; auth=none
X-Virus-Found:	No
X-Spam-SWARE-Status:	No, score=-1.6 required=5.0 tests=AWL,BAYES_00,PLING_QUERY,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=STILL, NEVER, surprise!, H*F:D*nl
X-HELO:	lb1-smtp-cloud2.xs4all.net
MIME-Version:	1.0
Date:	Mon, 29 May 2017 19:14:30 +0200
From:	Houder <houder AT xs4all DOT nl>
To:	cygwin AT cygwin DOT com
Subject:	Re: openssh: privilege separation no longer supported on Cygwin? SURPRISE!
In-Reply-To:	<20e2702ca3837f5d54c558f8e786c717@xs4all.nl>
References:	<d436698bbd53eef3cbdda788d4926109 AT xs4all DOT nl> <37b863f6-ce5c-ef13-569f-8044fe485075 AT gmail DOT com> <20e2702ca3837f5d54c558f8e786c717 AT xs4all DOT nl>
Message-ID:	<b16023ad6735108510ae351a8378a420@xs4all.nl>
X-Sender:	houder AT xs4all DOT nl
User-Agent:	XS4ALL Webmail
X-IsSubscribed:	yes

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

- Raw text -