Chroot Jail Not Secure for Sandboxing Python?

[gregpinero at gmail.com]

On Jun 25, 1:43 am, "Martin v. Löwis" <mar... at v.loewis.de> wrote:
> gregpin... at gmail.com schrieb:
>
> > This wiki page suggests using a chroot jail to sandbox Python, but
> > wouldn't running something like this in your sandboxed Python instance
> > still break you out of the chroot jail:
>
> >  os.execle ('/usr/bin/python','-c','import os; os.execlp("/bin/sh")',
> > {})
>
> Depending on how the chroot jail is set up, this command might not
> work - in the jail, /bin/sh might not exist.

I followed up with my ISP.  Here's the answer I got:

The os.exec call prepends the chroot directory to the absolute path,
but does NOT provide chroot for the child process.  However, as long
as the environment is maintained, which contains an LD_PRELOAD, the
"chroot" will also be maintained.  If  LD_PRELOAD is removed or
ignored, then the chroot is ineffective.

Another way of saying it is that every process is responsible for
providing and maintaining the chroot through the LD_PRELOAD variable.
Those processes only maintain the chroot if that variable remains set.

The only solution that would bypass this problem altogether would be a
statically linked python. (is that possible?)  It would have to be
statically linked to a custom-modified glibc to provide the virtual
chroot environment.

-Greg