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:reply-to:from:to:references:in-reply-to
	:subject:date:message-id:mime-version:content-type
	:content-transfer-encoding; q=dns; s=default; b=fvdgmvv+1So6A5lW
	B1DQsY8xaKX/aBeotTib9/Sn4fxBmT7BthOWJmjrpKuC/ni10v3+ioGHHEKYYbjZ
	HgUNBOuxe0sIgD3L/LbP6KEjtF+1Z34bwxP9bF6u+DPPVdVzNQdrVwj71KEyDy5e
	H/IKKkJYWy3uJQxNw8ts0x3Ywew=
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:reply-to:from:to:references:in-reply-to
	:subject:date:message-id:mime-version:content-type
	:content-transfer-encoding; s=default; bh=uCnEJa/omm+3btLHqUr2wm
	Ho5fc=; b=vDIi86wXExBDA8aAhxJQkA+av9fiVZd9XXp5RRW9ziH0EOxe427QE/
	W3ywzmc06sx+zsfvlKQEqmnaxNwfpPz0vhe6X/J+6A1RFo5imMr/EZnaOgljmJUL
	R/ze8EYBUKspLy68ocPS8bmf0bR1Wl4dTuKMx2V1U3YsRqHvxEEA4=
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=4.3 required=5.0 tests=AWL,BAYES_40,CYGWIN_OWNER_BODY,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD,SPF_PASS autolearn=no version=3.3.2 spammy=sk:CreateP, *caller*, sk:createp, gratefully
X-HELO:	resqmta-po-02v.sys.comcast.net
Reply-To:	<cygwin AT cygwin DOT com>
From:	"David Willis" <david_willis AT comcast DOT net>
To:	<cygwin AT cygwin DOT com>
References:	<019c01d163bc$fe2fc500$fa8f4f00$@comcast.net> <CANnLRdhVrFcveO_jKb3_x=44WMJNO33DPnsJZ12Wus3U7Wo_fQ AT mail DOT gmail DOT com> <019e01d163c2$d678c7e0$836a57a0$@comcast.net> <023901d165e4$925507d0$b6ff1770$@comcast.net> <87d1s1c8ld DOT fsf AT Rainer DOT invalid> <CACoZoo3R4CDcgTMMex9QZ=Wh9a8CDvyUHpqj5+Br5xYFvGHvuQ AT mail DOT gmail DOT com> <87a8n38t3r DOT fsf AT Rainer DOT invalid> <CACoZoo3831x0PVOQ9j6zh+Q4EE4-LFNV7KQsgeyooPJmvM7qVA AT mail DOT gmail DOT com> <20160215121101 DOT GC7085 AT calimero DOT vinschen DOT de>
In-Reply-To:	<20160215121101.GC7085@calimero.vinschen.de>
Subject:	RE: Possible Security Hole in SSHD w/ CYGWIN?
Date:	Tue, 16 Feb 2016 20:55:25 -0800
Message-ID:	<003801d1693f$6a5d71a0$3f1854e0$@comcast.net>
MIME-Version:	1.0
X-IsSubscribed:	yes

First let me say that I'm not too well-versed in coding and the ins and outs
of how processes utilize credentials when they are spawned. However, the
jist of it seems to be that if there are no credentials saved with passwd -R
to replace the current user token with that of the user that is SSH'd in,
then there is no way to change that token at all (or get rid of it) meaning
the token used when accessing a share will stay as the token of the caller -
namely cyg_server? Please correct me if I'm way off-base but that seems to
be my interpretation of this.

If that is the case, it seems this is an unintended side effect of the way
CYGWIN and sshd work together, and with the current state of Windows there
isn't really a way around it. And that's OK (I can work around it if that's
the case), I just wanted to get to the bottom of why this was happening and
let people know the situation because I wasn't sure if anyone was aware of
this behavior.

Thank you very much Erik and everyone else for the help with this. This is
my first time posting on these mailing lists and I appreciate people taking
the time to reproduce the issue and help work it out.

Thanks,

David

-----Original Message-----
From: cygwin-owner AT cygwin DOT com [mailto:cygwin-owner AT cygwin DOT com] On Behalf Of
Corinna Vinschen
Sent: Monday, February 15, 2016 4:11 AM
To: cygwin AT cygwin DOT com
Subject: Re: Possible Security Hole in SSHD w/ CYGWIN?

On Feb 14 13:36, Erik Soderquist wrote:
> I think the key point is that if no network password is stored using 
> the "passwd -R" option, then there should be absolutely no network 
> access at all in the current code/design, not a fall through to the 
> cyg_server account's network access, regardless of how much or little 
> network access that account has.

The problem is this:

I'm not aware of any explicit OS call which allows the process calling
CreateProcessAsUser to drop network credentials of the *caller* in the child
process running under another user token.

In fact, I'm not even aware of any call which allows to drop network
credentials even for the calling process, and that would be the wrong thing
to do anyway.

This is a clear cut case of "I need help" and "Patches gratefully accepted".


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat


--
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 -