Chroot Jail Not Secure for Sandboxing Python?

[gregpinero]

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")',
{})

or maybe:

del os.environ['LD_PRELOAD']
os.execl ('/usr/bin/python','-c','import os; os.execlp("/bin/sh")')

My ISP suggested these as counter-examples to my request for a chroot
jail. (I couldn't even get Python running in chroot to test this, nor
could I run these commands locally in Python on Ubuntu, though maybe
they opened sh?)

So is a chroot jail not adequate for sandboxing Python?

-Greg

[=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=]

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.

As others have mentioned (which I just repeat for additional
support): Your ISP is probably thinking of fakeroot, which
is entirely unlike chroot(2), with the latter being a proper
kernel mechanism, not dynamic library trickery (which would
indeed be easy to break out of).

Regards,
Martin

[gregpinero]

On Jun 25, 4:12 pm, Bjoern Schliessmann <usenet-
mail-0306.20.chr0n.. .@spamgourmet.c omwrote:

gregpin...@gmai l.com wrote:

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.

That sounds like rubbish to me. If it worked like that, chrooting
servers would be virtually useless.

You're right. It turns out he was referring to fakechroot. Chroot
shouldn't have this problem.

-Greg

[=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=]

To launch a child process in a chroot you can easily just fork and

then make the chroot syscall in the child process immediately after
the fork.

It's not so easy. On Linux, you need to have the CAP_SYS_CHROOT
capability to invoke the syscall; on other systems, you may have
to be root.

Regards,
Martin