This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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
something wrong):

The "status quo" regarding Chroot in Cygwin is: This is  only a "path
filter", and only for file handling done exclusively through the posix
(cygwin) API;
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
non-negotiable :)
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 :)

Julio Costa

Problem reports:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]