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:subject:to:references:from:message-id:date :mime-version:in-reply-to:content-type :content-transfer-encoding; q=dns; s=default; b=gaJljrR+TtNKQGSL ArdtrSqe9RVB1F4aDp0D9QicEhUAB+O+DOlkijiA6pkyoBaNcqL9vkf/P5HNMN9M fv1k9mLUyDNsg0FFxUC4ezlM+3UXnScmOTedvdeqphvoPZ9ck6xI2Mg5Kk5s8Oyi uT7RtGelkKTn3qwhF9i1kngwtKM= 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:subject:to:references:from:message-id:date :mime-version:in-reply-to:content-type :content-transfer-encoding; s=default; bh=0NgICrVwZ6YCg/8OL8vMzZ GSIHM=; b=CPRzHEVgmItfDJ3g6ZWNTkkPtOcyDfSS5/tpsV5l27/rAxj+OyVB3/ wHH7A0zt6elKzUzChrQf0yEGBgN37jz6pls+hq1IpNunRKslPiqDyFJM7KBhEkK5 918nfkz3y4uzg4vPjFE8n1ye/vbwhXRa+QPT6UbpzMTsIs+r1xmLI= 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-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=bills, Bills, locked, H*UA:6.1 X-HELO: mout.gmx.net Subject: Re: sshd permits logon using disabled user? To: cygwin AT cygwin DOT com References: <1690850474 DOT 834980 DOT 1548391349102 DOT ref AT mail DOT yahoo DOT com> <1690850474 DOT 834980 DOT 1548391349102 AT mail DOT yahoo DOT com> <20190125174833 DOT GA1710 AT zebra> <20190127221047 DOT GI3912 AT calimero DOT vinschen DOT de> From: Sam Edge Openpgp: preference=signencrypt Message-ID: <502557d3-3fa3-e0eb-127a-ed2026f949a7@gmx.com> Date: Mon, 28 Jan 2019 13:36:15 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <20190127221047.GI3912@calimero.vinschen.de> Content-Type: text/plain; charset=utf-8 X-IsSubscribed: yes Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id x0SDZf9s002568 On 27/01/2019 22:10, Corinna Vinschen wrote: > On Jan 27 17:49, Sam Edge (Cygwin) wrote: >> On 25/01/2019 18:03, Bill Stewart wrote: >>> On Fri, Jan 25, 2019 at 10:48 AM Stephen Paul Carrier >>> wrote: >>> >>>> There are different paths to access and to completely disable the account >>>> you need to close all of them. There are many reasons to disable some >>>> paths without disabling all paths and converting the switch that can >>>> disable one path to a switch that will disable all paths will break >>>> some setups and be less flexible. (As Stefan Baur is pointing out >>>> effectively.) >>>> >>>> To disable ssh logins really, instead of changing the way Cygwin works >>>> for everyone, you could do what UNIX/Linux admins do, something like >>>> moving the user .ssh folder to .ssh.disabled. >>> This is a very problematic view from a Windows system management perspective. >>> >>> I respectfully (and strongly) disagree, for at least the following reasons: >>> >>> * Cygwin runs on Windows, and as such should respect Windows security. >>> It is very unexpected, from a Windows administration perspective, to >>> have a disabled account and still be able to log onto it. >>> >>> * Proper system management/security mitigation is made quite complex >>> with this requirement. Imagine even a small Windows domain: I have to >>> scan 20000 machines in my domain to find out if they're running ssh, >>> troll through the disks to find ssh config files, find out the key >>> file names, rename them, etc. This is quite a bit harder to do than >>> just disabling accounts, which in many organizations is handled by an >>> automated process. >>> >>> Regards, >>> >>> Bill >> >> I totally agree that Cygwin should respect the Windows disabled & >> locked-out semantics and disallow any form of login where either is set. >> Trying to shoe-horn the disabled password but enabled pubkey function >> into one or the other just doesn't feel right. Setting a hugely long >> random password (maybe via a script that never reveals said password) is >> a much better solution to achieve a similar effect without breaking >> Windows security auditing. >> >> On the other hand, I am baffled as to why Windows itself allows a token >> to be created for an account that is disabled or locked out. If Cygwin >> can do it, other programs could too so you're still vulnerable. > No, Windows doesn't allow that unless the process has very specific > privileges. But keep in mind that a token is required to do stuff on > behalf of a user. So even if the user is disabled from interactive > logon, a service process might have a valid reason to create a token > for that user to perform a non-interactive purpose. > > In terms of these special privileges, right now we require these > privileges for an account which switches the user (e.g., via sshd > installed as a service), as outlined in > https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-nopasswd1 > > However, this should change with the upcoming 3.0 release of Cygwin > which replaces the "create token" method with another method called > "S4U". This method creates perfectly valid tokens with only documented > functions without requiring any super-special permissions. > > I'm pretty excited about this change because it drops the requirement > to create a special CYgwin service account. sshd and other services > can finally run under the normal LocalSystem account again. > > This patch is available in the most recent developer snapshot from > https://cygwin.com/snapshots/ btw. > > > Corinna > Hi Corinna. Thanks for the explanation. And the heads-up on the change. Having a rummage through docs out of curiosity. (Tangential to my day job.) I think I grok Win32 and Linux FS ACLs but my expertise on OS process security models peaked somewhere around System V. :-S Anyway, the fact that activity can still occur in the name of disabled/locked-out accounts is, perhaps, something that people in Bill's position should consider, given his concerns. But that's rather OT. As ever, kudos to yourself and the rest of the contributors to Cygwin. Still my go-to tool wherever I land. -- 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