[ On Fri, October 2, 1998 at 14:04:57 (+1000), matthew green wrote: ]
> Subject: re: chroot(2) 
>
> i've always hated chroot(2)'s inability to correctly deal with
> leter normal users do this.  from a security perspective, the
> functionality is really nice, but having to be root *first* is
> a lose...

One might argue for this by trying to draw the simile that it's really
only safe to let a being with supreme powers shut someone else into
purgatory for eternity.

there are a *lot* of things you need to turn off for any non-root
process that wants to lock itself in a chroot'ed jail.  You essentially
have to assume there are only two valid user-ids, that of the process
and zero, and you can't allow any setuid exec(), no mknod(), no symbolic
or hard links out of the jail, and probably a bunch of other things I've
forgotten, and of course setting up such a jail in a safe configuration
is non-trivial.

That said though I think I will agree that it's safer to turn off
certain system functions and features for chroot'ed processes than it is
to assume the jail maker knows what they're doing.

I think though it would be a good idea to invent a whole new interface
to such a feature as a non-root chroot() than it would be to change the
existing chroot(2) interface.  Perhaps it could be called jail(2)?  ;-)

I would suggest that to be more provably safe something like this would
have to exec a new binary that finds itself fresh in the jail with only
stdin, stdout, and stderr possibly attached to anything external.
I.e. I'm thinking of ways to ensure there can be no data left in the
process' space from when it was in a more privileged state.

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>