Chroot Jail Not Secure for Sandboxing Python?

[David E. Konerding DSD staff]

On 2007-06-25, 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:
>> 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.

None of this makes any sense to me.  Once an application is running
inside a chroot, there is no easy manipulation the application
can do "to break out".  The example you gave above executes a shell that
is in the chroot dir.  That's not really breaking out of the sandbox,
it's just accessing something inside the sandbox.

if your ISP is trying to enforce chroot through an LD_PRELOAD library,
they might be using 'fakechroot' which doesn't look very good to me.

Dave