Joey Hess wrote:
Greg Norris wrote:

Has anyone here has tried out chroot_safe[1]?

I haven't read any of the code, but based on their documentation, so long as you trust the binary you're chrooting, it should be as safe as regular chroot. The paranoid part of me suspects that a malicious binary could run under chroot_safe and manage to avoid running chrooted, although it might have to find an exploit a hole in chroot_safe to do so.

Looking at the code, it seems as though chroot_safe simply uses the normal chroot() call; I would think the binary running would not be able to see the difference between `real' chroot and chroot_safe (and should thus not be able to exploit bugs in chroot_safe).

But as long as you trust the binary program you're chrooting, and
are only concerned about its behavior when fed untrusted data or the
like, after being chrooted, this seems like a perfectly safe and rather
handy way to go about chrooting it.

Oh and also, there's no reason a simple program without LD_PRELOAD magic
couldn't automatically set up a chroot environment for a program to run
in.

Indeed. chroot_safe looks interesting, but I fail to see why they choose the name "chroot_safe". I see nothing in the code (or the description) that makes it safer than real chroot. It does make it a lot easier to set up a chroot environment, that is what LD_PRELOAD is used for: with the chroot_safe.so library in LD_PRELOAD, you don't need to fill /bin, /lib/* etc with everything you normaly need to get chroot running.

I think a better name would have been "chroot_simple", or "chroot_easy".


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]




Reply via email to