Chroot Jail Not Secure for Sandboxing Python?

[gregpinero at gmail.com]

On Jun 25, 11:58 am, Paul Boddie <p... at boddie.org.uk> wrote:
> On 25 Jun, 16:48, "gregpin... at gmail.com" <gregpin... at gmail.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.  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.
>
> So it appears that as long as LD_PRELOAD is set (possibly to link the
> process to some other libraries than is usually the case), any
> affected processes are effectively jailed. This doesn't really sound
> like a traditional chroot environment, though.
>
> > 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.
>
> Right.
>
> > 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.
>
> Some solutions depend on linking to restricted libraries, and the Wiki
> page you referenced probably talks about them as well. I was thinking
> that if I were to attempt to properly sandbox  any current version of
> CPython, I'd start off linking it to restricted libraries which
> provide compatible interfaces for things like opening file handles;
> then I'd put various policy controls in those libraries so that you
> can have some control over what your programs do. Finally, you'd have
> to stop arbitrary (extension) module loading in order to prevent
> programs importing some nice modules and getting round the controls:
> for example, importing socket or os to get access to file handles (or
> to process creation which might get around the controls as suggested
> above). Eventually, this arrives more or less at where Brett Cannon is
> supposed to be right now with his sandboxed Python, perhaps by a
> different route and with some different outcomes.

It looks the like only option available to me right now is fakechroot,
which really doesn't sound like it's going to work.  So I'm going to
give Bett Cannon's stuff (http://sayspy.blogspot.com/2007/05/i-have-
finished-securing-python.html) a try.

I've never compiled my own Python from source before.  Are there any
tutorials on this?
Wish me luck :-)

Thanks for all the help on this question.

-Greg