Chroot Jail Not Secure for Sandboxing Python?
josiah.carlson at sbcglobal.net
Mon Jun 25 17:05:51 CEST 2007
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.
More information about the Python-list