> This was my thought too. I just figured there was something special > about this command that brought one to the "real" Python intrepreter > and then to the real "/bin/sh". That's odd, my ISP seem adament that > this is a way to break out. I'll just have to put in the work to test > to locally I guess.
No. The jail is protected by the operating system - even if a perpetrator would manage to run arbitrary native code (e.g. through running a compiler) in the jail, they *still* could not access any data outside the chroot. There are very few way of getting out of the jail. One is to manage creating a device node for, say /dev/hda, and then mounting hard disk into the jail; others are listed at http://www.unixwiz.net/techtips/chroot-practices.html In all cases, you need root privileges, so if the chrooted process does not run as root, it is safe. Be careful not to put any s-bit programs into the jail. >>> So is a chroot jail not adequate for sandboxing Python? >> You have to define your threat model. If the threat to prevent is >> a malicious user getting at your data, or spreading a virus >> through your files, then chroot is perfectly adequate. > > Yeah, sounds like my threat model. Maybe prevent someone sending > spam, or DOS from my server too. It cannot help you prevent the sending of spam or DOS: it *only* affects the local hard disk (that's why it's ch*root* - as in "root directory"). The "jailed" process can perform all networking that a similarly-privileged process outside the jail could. To prevent network access, you would need additional system features, as the ones provided by SELinux. Regards, Martin -- http://mail.python.org/mailman/listinfo/python-list
