On 6/25/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > On Jun 25, 11:58 am, Paul Boddie <[EMAIL PROTECTED]> wrote: > > On 25 Jun, 16:48, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> -- http://mail.python.org/mailman/listinfo/python-list
