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 implementation! =========================================================== 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 transfers; 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: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
