X-Recipient: archive-cygwin AT delorie DOT com
X-Spam-Check-By: sourceware.org
Message-ID: <49367676.B871851B@dessent.net>
Date: Wed, 03 Dec 2008 04:07:18 -0800
From: Brian Dessent <brian AT dessent DOT net>
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: Finally managed to create a jailed SFTP server, but how secure?
References: <664060 DOT 6380 DOT qm AT web34704 DOT mail DOT mud DOT yahoo DOT com> 	 <961872 DOT 64997 DOT qm AT web34701 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> 	 <af075b00812030245m2b64cae2q4601c63424da611 AT mail DOT gmail DOT com> 	 <49366705 DOT 5D2D6371 AT dessent DOT net> <af075b00812030338m3708cadv40a62bdde5a2340d AT mail DOT gmail DOT com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes
Reply-To: cygwin AT cygwin DOT com
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

Julio Emanuel wrote:

> Aha! So this is the tiny bit that was missing! What you are saying is
> that the Cygwin DLL does not honor the chroot if the path is in WIN32
> format? But why is that? It shouldn't honor the chroot all the time?
> I mean, this sounds like the "right thing to do"(tm), if Cygwin is
> supposed to fully support chroot environments...

I haven't verified that this is the case, but I suspect that it is.  The
general philosophy of most of the path handling code is that Win32 paths
bypass all Cygwin logic entirely.  There are still lots of people that
try to use Win32 paths with Cygwin tools despite the fact that it's not
supposed to be how things are done (and discouraged.)

As to whether it should try to special-case this situation and disallow
the use of Win32 paths if a chroot is in effect, I'm not sure if it
makes sense.  As others in the thread have already said, the chroot
feature is meant to be "necessary but not sufficient", if you will. 
I.e. it's a convenience, not an enforecement.

Most of the time when you encounter a program that's been put in a
chroot jail the reasoning is so that if there is some kind of
exploitable vulnerability in that program an attacker cannot gain access
to the rest of the system outside of the jail.  In this scenario the
chroot provided by Cygwin provides zero protection, because if the
attacker can run exploit code then can just call directly to the Win32
APIs and bypass Cygwin entirely.  No amount of protection in the DLL
will ever change this basic fact, so just seems to me like you'd be
furthering the illusion of security by trying to add more checks.

Brian

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