Subject: Re: chroot(2)
To: None <firstname.lastname@example.org>
From: Warner Losh <email@example.com>
Date: 10/14/1998 13:20:18
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
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.