Chroot Jail Not Secure for Sandboxing Python?

[Nick Craig-Wood]

gregpinero at gmail.com <gregpinero at gmail.com> wrote:
>  On Jun 25, 1:43 am, "Martin v. Löwis" <mar... at v.loewis.de> wrote:
> > 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 all depends on how much stuff you put in your chroot!

If you don't put bin/sh in the chroot then you'll stop a lot of
exploits from working.

If you don't allow the chrooted user write permission to the chroot
then you will anyone uploading a shell or any other binaries, just
leaving you with the binaries in the chroot to worry about.

Nothing stops someone running os.fork() from python and spawning
processes to do bad stuff.  However in order to do that they would
have to have compromised your .py and sent some code to exec(), or
found a buffer overflow within python.  It is getting increasingly
unlikely but not impossible.

Note that root can break out of a chroot, so your users must
not be root in the chroot.

Chroots provide a reasonable level of security. If you are truly
paranoid about security then you want to check out selinux (as made
originally by the NSA).

>From the selinux FAQ :-

  The Security-enhanced Linux kernel enforces mandatory access control
  policies that confine user programs and system servers to the
  minimum amount of privilege they require to do their jobs. When
  confined in this way, the ability of these user programs and system
  daemons to cause harm when compromised (via buffer overflows or
  misconfigurations, for example) is reduced or eliminated.


-- 
Nick Craig-Wood <nick at craig-wood.com> -- http://www.craig-wood.com/nick