David Willis writes:
> I know this is a somewhat unique and I guess obscure issue, but if someone
> could please look into this - I would be very surprised if it was NOT
> reproducible following the steps below. Because if this is actually the case
> it is in fact granting permissions that it should not be granting to SSH
> users that log in using public keys.

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.

> Like I said, there is no error message or anything (due to the nature of the
> issue) but the steps to reproduce are as follows:
>
> Cyg_server is the privileged account used by CYGWIN for SSH privilege
> separation, and is a DOMAIN account, and a member of DOMAIN ADMINS

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.

> User on the domain (a regular-privileged domain user) logs into another box
> on the domain using public key method (NOT password). He logs in as himself,
> which has regular non-admin privileges on both the client and server
> boxes.

Unless that account can authenticate fully on that box (i.e. there's a
password), it doesn't have network access.

> The client box is either Linux or Windows w/ CYGWIN, but the SSH server must
> be CYGWIN.
>
> After connecting to the CYGWIN SSH server, the user CD's to a Windows server
> file share's UNC path - i.e. "cd //[SERVER]/[share]"

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.

> Now you check Computer Management on the file server, check Shared
> Folders->Sessions, and you see that instead of the user having an open
> session, the cyg_server user has an open session (from the machine that you
> SSH'd to).
>
> The user now has access to anything that cyg_server would have access to.
> Since cyg_server is a domain admin, that would be pretty much everything
> aside from shares that are specifically locked down to certain users and not
> allowing admins.

Don't make cyg_server a domain admin, then.

> I don't know if this bug is with SSH or CYGWIN, but it only occurs on CYGWIN
> SSH servers (not Linux SSH servers, although its hard to test because when
> SSH'd into a Linux box I can't CD directly to a UNC path, I have to mount
> the share instead, and specify user credentials to do so).

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.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Terratec KOMPLEXER:
http://Synth.Stromeko.net/Downloads.html#KomplexerWaves

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

Reply via email to