in reply to Re: Re: Running untrusted perl code
in thread Running untrusted perl code

The idea is to have a mini-system in the chroot tree and call an effective chroot /path/to/sandbox /bin/script where script actually is in /path/to/sandbox/bin. You will need to set that up, however you call it, suid root, and need to release root privilege before any user code is evaled. A small C program may be the simplest to set up. Any system utils you permit will need to be copied into that tree in their customary locations. They should be static builds unless you want copies of all the needed system dll's.

Not even root can break out of a properly set up sandbox. The perl installation is needed the same as any other executable. If it's not in the sandbox it effectively doesn't exist for the jailed process.

If you lack privilege to secure this, you probably shouldn't be doing it.

After Compline,
Zaxo

Replies are listed 'Best First'.
Re: Re: Re: Re: Running untrusted perl code
by BUU (Prior) on May 31, 2004 at 04:58 UTC
    I know what the point of chroot is, (but note, according to http://www.bpfh.net/simes/computing/chroot-break.html it is possible to break out of a chroot jail, assuming you are root), if you'll notice in my original node I am planning on using chroot, my question was, why bother installing perl and so forth in my chroot directory? I plan on just chrooting my child process thats going to eval the untrusted code, that way I can leave the chroot directory completely empty.