Chroot Jail Not Secure for Sandboxing Python?

[Josiah Carlson]

gregpinero at gmail.com wrote:
> 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.

It seems to me that if a (potentially malicious) process needs to behave 
itself in order for chroot to not allow the process access to the full 
system, then chroot is broken.  But perhaps I don't understand the 
intent and scale of what chroot intends to do.


  - Josiah