Chroot Jail Not Secure for Sandboxing Python?

["Martin v. Löwis"]

> 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