Chroot Jail Not Secure for Sandboxing Python?

[Evan Klitzke]

On 6/25/07, gregpinero at gmail.com <gregpinero at gmail.com> wrote:
> 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.

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.

-- 
Evan Klitzke <evan at yelp.com>