In message <Pine.GSO.3.95.981013123918.8592A-100000@jericho> "Eduardo E. Horvath" writes:
: You're missing the original context.  We were discussing allowing
: chroot(2) to be used by non-root users and the security implications.
: After a huge list of changes that would need to be made I suggested that
: things were getting complicated and most of the security coult be achieved
: if the set[gu]id bits were ignored after a user did a chroot(2).  Then the
: only other major hole would be device nodes.

and loadable device drivers....

I think that it should be possible for root to allow for the set[gu]id
bits to be honored.

However, it would be trivial to mark a process as chroot and then
check the set[gu]id bits at exec time.  It would also be possible to
have a similar check before the creation of device nodes.  That would
just leave the "jail break" problem, since if you can somehow get root
in a chroot'd envornment, then you can break out to the rest of the
system.

Ignoring set[gu]id bits on exec would certainly be sufficient for
things like tar doing a chroot to get around some security problems
that were discussed in bugtraq recently (which started this whole
thread, iirc).  However, I don't know if it would compromise the
system in other ways.

Chroot also doesn't revoke open files that reference outside of the
chroot'd area, nor does it do a chdir(2).  This also bothers me for
reasons I can't quite put my finger on.  If a chroot caused a chdir
and a revoke, then all of the chroot jailbreak programs that I'm aware
of cease to work.

Warner