[EMAIL PROTECTED] wrote:
> On Jun 25, 1:43 am, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>> [EMAIL PROTECTED] 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
--
http://mail.python.org/mailman/listinfo/python-list
