On Tue, Oct 11, 2005 at 12:29:35PM +0200, Alfred M. Szmidt wrote:
A obvious security exploit in the chroot() implementation (or really,
file_reparent) and not in how passive translators work. If you want a
secure chroot enviroment (right now atleast) then you should run a
sub-hurd. Where this isn't possible (atleast, I have never been able
to break out of a sub-hurd, and I have tried). So instead of using
broken UNIXoid ideas like chroot, it would make far more sense to
implement a light-weight sub-hurd which can be used like chroot.
A problem here is that programs aren't and shouldn't be written solely for the
Hurd. People should want to write portable programs, which means they don't
want to use platform-specific extentions. This means a library is needed for
them. But chroot exists, and if you replace it by a library call, nobody will
use it.
The obvious solution in this case would be to make chroot a libc call which
really just builds a sub-hurd. However, I don't think that solves all the
problems. Having the filesystem construct a "sane" environment is a very
fragile approach, and persistance sounds like a better solution to the
problem. However, that has its costs as well, and I have no idea how big they
are.