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: List-Subscribe: List-Archive: List-Post: List-Help: , 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 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 29 May 2017 19:14:30 +0200 From: Houder To: cygwin AT cygwin DOT com Subject: Re: openssh: privilege separation no longer supported on Cygwin? SURPRISE! In-Reply-To: <20e2702ca3837f5d54c558f8e786c717@xs4all.nl> References: <37b863f6-ce5c-ef13-569f-8044fe485075 AT gmail DOT com> <20e2702ca3837f5d54c558f8e786c717 AT xs4all DOT nl> Message-ID: 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