X-Recipient: archive-cygwin AT delorie DOT com
X-Spam-Check-By: sourceware.org
Message-ID: <af075b00812050243re11fd22qa2715223ad508b8b@mail.gmail.com>
Date: Fri, 5 Dec 2008 10:43:41 +0000
From: "Julio Emanuel" <costaju AT gmail DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: Finally managed to create a jailed SFTP server, but how secure?
In-Reply-To: <5E25AF06EFB9EA4A87C19BC98F5C87530208D531@core-email.int.ascribe.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <664060 DOT 6380 DOT qm AT web34704 DOT mail DOT mud DOT yahoo DOT com> 	 <493568B8 DOT 3010308 AT cygwin DOT com> 	 <49376 DOT 99112 DOT qm AT web34702 DOT mail DOT mud DOT yahoo DOT com> 	 <20081202231141 DOT GA5449 AT ednor DOT casa DOT cgf DOT cx> 	 <451120 DOT 45664 DOT qm AT web34703 DOT mail DOT mud DOT yahoo DOT com> 	 <4935DD4B DOT 7050907 AT cygwin DOT com> 	 <690548 DOT 2534 DOT qm AT web34702 DOT mail DOT mud DOT yahoo DOT com> <4936FEA1 DOT 705 AT cygwin DOT com> 	 <828494 DOT 98789 DOT qm AT web34707 DOT mail DOT mud DOT yahoo DOT com> 	 <5E25AF06EFB9EA4A87C19BC98F5C87530208D531 AT core-email DOT int DOT ascribe DOT com>
X-IsSubscribed: yes
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Id: <cygwin.cygwin.com>
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT 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

On Fri, Dec 5, 2008 at 2:24 AM, Phil Betts <Phil DOT Betts AT ascribe DOT com> wrote:
>
> Frankly, there are loads of things that you would need to test and
> you can never be sure you've checked all possible mechanisms.  Given
> that the chroot jail is really an open prison under Windows, one has
> to wonder if it's worth the effort, and what you have proved if all
> of your tests have passed.
>

That's a good point. In fact, written that way, it's an universal
point, because you can always think "where are those holes that I
didn't test about"? :)

Now seriously, we have to think where is the responsibility to
"filter" (I think this is the best describing word for the chroot
implementation on cygwin) the non-valid paths under chroot
environment...
Unless there is specific code in sftp/sshd to handle and filter out
the DOSish paths (which I seriuosly doubt, but the maintainer can
correct me), this is already been filtered in the cygwin dll.
If it is so, Corinna, maybe the implementation is in a bit better
shape than you remember? Can you confirm that this is result from
chroot implementation in cygwin dll? (just morbid curiosity, at this
stage :)

> The best you can say is that you are protected against inadvertent
> access and (possibly) someone casually poking around.
>

Well that is always better than to make available the whole file
system in from of their eyes, isn't it?
You all have probably heard/read a lot, "Security by obscurity" is not
nice, very dangerous, and produces a fake sense of security - and all
it's true, in the right scenarios.
However, I can tell you, whithout a trace of doubt, "Security by
obscurity" ALWAYS wins NO security at all, if you know what you're
doing.
For what is worth, my professional field is indeed security, almost
ten years of it.
As for anything done with proper sense of professionalism, this have
to be weightned against your acceptable level of risk.
But for (e.g) casual file-transfer between in-house servers, I would
always recommend this kind of implementation because it is much better
than a whole-open sftp... or (argh) ftp and the like...

> Don't forget that even if you decide SFTP is "secure enough", you
> need to consider the system as a whole.  One of the problems with

Nothing is 100% secure, so the "secure enough" IS the key, and that is
another way to refer to the acceptable level of risk.
So this advice is true anywhere, anytime. But regarding this SFTP
implementation, what I (and TheO too, I suppose) want to know is not
the myriad of ways that security can go wrong; but only if the chroot
filtering (strictly inside of SFTP implementation) is honored.

From what we've seen so far, it seems that SFTP responds as expected.
That is all that I want to know.
From this point forward, we must try to close all other access ways
that does not belong to the scenario... but those are not excuses to
not implement the SFTP chroot.

> Windows' security in general is the number of open ports and services
> that are running.  If unauthorized users are able to gain access to
> the system via any other route, then any security SFTP gives you is
> totally illusory.  You would really need an external, aggressive
> firewall to be sure that the only possible external access was via
> SFTP.

... and that is a good advice - even though that could be
insufficient, depending on the projected use of the SFTP, and it's
position in the network architecture, etc. In short, YMMV.

> You can't rely on just disabling services, because I have
> known them to become enabled again after installing updates (thanks
> MS!)
>
> Phil
> --

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/