From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 112417 invoked by alias); 13 Feb 2016 21:15:36 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 111863 invoked by uid 89); 13 Feb 2016 21:15:28 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=2.9 required=5.0 tests=AWL,BAYES_50,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=EVERY, polite, arguing, mitigate X-HELO: resqmta-po-07v.sys.comcast.net Received: from resqmta-po-07v.sys.comcast.net (HELO resqmta-po-07v.sys.comcast.net) (96.114.154.166) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Sat, 13 Feb 2016 21:15:26 +0000 Received: from resomta-po-04v.sys.comcast.net ([96.114.154.228]) by resqmta-po-07v.sys.comcast.net with comcast id HxFC1s0034vw8ds01xFQV3; Sat, 13 Feb 2016 21:15:24 +0000 Received: from HOME1 ([24.18.54.164]) by resomta-po-04v.sys.comcast.net with comcast id HxFP1s0073YafjL01xFPYo; Sat, 13 Feb 2016 21:15:23 +0000 Reply-To: From: "David Willis" To: References: <019c01d163bc$fe2fc500$fa8f4f00$@comcast.net> <019e01d163c2$d678c7e0$836a57a0$@comcast.net> <023901d165e4$925507d0$b6ff1770$@comcast.net> <87d1s1c8ld.fsf@Rainer.invalid> In-Reply-To: <87d1s1c8ld.fsf@Rainer.invalid> Subject: RE: Possible Security Hole in SSHD w/ CYGWIN? Date: Sat, 13 Feb 2016 21:15:00 -0000 Message-ID: <024901d166a3$a6930390$f3b90ab0$@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2016-02/txt/msg00201.txt.bz2 First of all, it is one thing to ask me why I have set this up the way I did - its another to tell me I've set it up "wrong", especially without known the ins and outs of my domain and network. > You still do not seem to have understood what > > https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-setuid-overview > > is trying to tell you. The windows box you log into _must_ have a password > for the user that logs into via SSH using one of the methods listed there in > order for the user credentials to become valid on the network. So you're telling me any user that logs in using key authentication cannot access the network as the same user (i.e. this is the intended behavior)? If that's the case wouldn't it be better not to allow network access at ALL, rather than allowing it as the service account that sshd is running as? > Just why do you think that cyg_server should be a domain admin? It only > needs local admin membership plus some capabilities that allow it to create a > new user token. Does it have those capabilities at all, i.e. what does > > editrights -lu cyg_server > > produce as output? If it doesn't have them, then it can't actually switch the > user, password or not. Yes it has those capabilities. I don't "think" it "needs" to be a domain admin - yes there are other solutions such as making it a local admin individually on each box running sshd, but currently I don't have a GPO setup to do that, and doing it individually on each machine that runs sshd is impractical. I am looking to implement a GPO that does just that at some point in the near future but this is the way it is setup currently in order to give it local admin rights on all boxes. Like I said, I agree there are better ways of going about this and I'm not saying the current implementation is best practice but this is what I've got to work with currently. And yes I know about the other rights it needs - Act as a part of the OS, Create a token object, Log on as a service and Replace a process-level token. There are GPOs in place to give it those rights based on the groups it is in. There are also GPOs in place to prevent it from logging in interactively or through terminal services - the ONLY logon method right it has is to logon as a service. This is BECAUSE of the fact that it is a domain admin account, to mitigate the access it has on the domain. > Unless that account can authenticate fully on that box (i.e. there's a > password), it doesn't have network access. > > This would fail if you've not set up cyg_server as a domain admin, if you've > even got that far. In fact you'd not be able to use any shares that require > authentication. Again, so this is intended behavior when logging in with keys? And furthermore you are saying the only reason that I have network access as the cyg_server account is because it is a domain admin, and if it was not, there would be no network access whatsoever? So if I am hearing this right, anyone using SSH with key authentication instead of password authentication, has NO network access through SSH sessions at all? That seems unlikely, but if that's the case then so be it. > Don't make cyg_server a domain admin, then. Again, that is the current setup that I have to work with. And again, yes I plan to implement a GPO to instead grant it local admin rights on each box so that it does not need to be a domain admin to have those rights, but that is not in place yet. Not arguing about what is best practice here, just trying to get to the bottom of why this issue is occurring. > I don't know how you've arrived at the setup you just described, but it's not > the one that sshd_host_config produces. Yes, setting up an SSHD wrongly > can open up security holes, no surprise here. Yes you're right, it is not the one that ssh_host_config produces. Ssh_host_config would create a SEPARATE local admin account on EVERY box its run on. That is impractical to manage on a domain and not the setup I want. Hopefully now you understand a little more why I've arrived at the setup I have. I need a setup that is manageable at the domain level - I do not have the time or resources to manage local accounts each box running sshd individually, grant them each their own individual rights, etc. I know cyg_server needs LOCAL admin rights - the old way of implementing this was to use a domain account so that we don't have separate local accounts on each box, and make it a domain admin to grant it admin rights on all servers and workstations. I fully understand that this is not a best practice, and like I said, there is a GPO setting that will allow local admin rights on all boxes to a domain user w/o making them a domain admin, and this is exactly what I plan to implement in the near future. However it is not implemented currently, so this is the situation I am facing right now. If you are saying without domain admin rights there would be no network access at all granted, well, I guess that's a solution. I prefer to keep password authentication DISABLED for security reasons (which is highly recommended by numerous guides, including the Cygwin site itself if I remember correctly). If however key authentication means no access to network shares whatsoever (assuming the service account is not a domain admin), that seems to make things difficult. As a closing note, I've been polite here asking for help, pointing out a possible issue. It would have been very easy to say something like "normally no network access is allowed when logging in w/ key authentication, and making cyg_server a domain admin is the only reason this issue is occurring, and it is not a recommended best practice" and I would say OK thank you very much I understand that and it makes sense. Instead of going to great lengths to tell me how "wrong" my setup is and implying that I know nothing about what I'm doing. You do not understand why people have things setup the way they do and there may be reasons behind it. So I would not be so quick to say that people have things setup "wrong" - you could just say "if you go with that setup, this will be an unintended side effect". I can assure you I do understand the rights that cyg_server needs to function, why cyg_server was made a domain admin and why I do not "go with the default setup that ssh-host-config" provides". The one thing I did not understand was that authenticating with a key was NOT equivalent to authenticating with a password. I now understand that fact - I would now suggest that in the documentation you explicitly point out that when logging in w/ key auth, you have the rights on the network that cyg_server has. I don't think that point is explicitly made in the documentation, and I don't think it would be a bad idea to do so. Thanks, David -- 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