This is the mail archive of the
mailing list for the Cygwin project.
Cygwin Chroot security considerations [WAS: "OpenSSH - sftp not working for non-Administrator users"]
- From: Julio Costa <costaju at gmail dot com>
- To: Cygwin Mailing list <cygwin at cygwin dot com>
- Date: Tue, 6 Oct 2009 15:21:08 +0100
- Subject: Cygwin Chroot security considerations [WAS: "OpenSSH - sftp not working for non-Administrator users"]
On Tue, Oct 6, 2009 at 10:15, Corinna Vinschen wrote:
> I wrote this on this list a couple of times and I'm writing this again, as long as
> anybody wants to read it: Chroot is a bad hack, bad fake on Cygwin and
> I curse the day I added this to Cygwin.
Please don't. It isn't a bad hack. Its a step forward to a proper
chroot implementation, even if currently it's not even half way there.
And it is always useful if you know how to handle with its shortcomings.
Now there is an important statement that is useful to put with all
emphasis for all future searchers out there:
Cygwin chroot is NOT a full (not even half) implementation of a Unix chroot.
Don't expect Unix chroot-like security using the current Cygwin chroot
There. Now I wrote it too. :)
Now that everyone got their warning, it would be extremely useful to
enlist what are the specific shortcomings so that anyone who still
wants to try that knows what is expected, about the (in)security of
the solution. I'll give my 2cents here (correct me please if I say
The "status quo" regarding Chroot in Cygwin is: This is only a "path
filter", and only for file handling done exclusively through the posix
So, the (big-as-a-whale) security hole is basically - anything that
can call any Windows API file handling function!
To control this, the security controls/ recommendations are:
1) ONLY setup chroots for Non-Admin users. Failing that, and there's
no way (ever!) to control the user's actions. REALLY, it's
2) Setup the chroot so that there are NO writable files/directories -
exception would be, of course, a single /pub dir to make file
3a) Setup a restricted shell (rbash comes to my mind, although I'd
prefer something more "light") so that there is no possibility to
execute anything besides the commands made available; **This is to
avoid a download of a script/exe to /pub and then execute it**. That's
where the HOLE is right now.
3b) OR, use a suitable ForceCommand on sshd_config, although
"suitable" will widely depends on the objectives for using sshd.
As far as I can tell, and with a bare minimum commands in /bin, there
is a possibility of getting things minimum secured, at least for the
popular use of sshd, as a sftp/scp provider for secure file transfers.
NOT as a general ssh remote shell service - not a chance!
> Don't use chroot and think
> you're safe. You're not. It's just a joke of a jail. Don't put too
> much work into it. I, certainly, won't.
I certainly will. That's because this is better than nothing, **if you
know what you are doing**, and **if you don't expect a Unix chroot**.
Nevertheless, it's already an evolution from plain *blerg* Windows.
As soon as I've my scripts stabilized, I'll share with you my way of
setting this up, in a (hopefully) secure way.
Please stay tuned... but don't hold your breath :)
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple