On Fri, Dec 5, 2008 at 2:24 AM, Phil Betts <[EMAIL PROTECTED]> 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/
