Re: can chroot be made safe for non-root?

[Shaya Potter <spotter@cs.columbia.edu>]

On Fri, 2002-10-18 at 17:00, David Wagner wrote:
> Shaya Potter  wrote:
> >the problem with chroot() is that they dont nest.
> 
> That's *a* problem, but not (IMHO) the most significant problem.
> The biggest disadvantages with chroot() (as I see it) are:
>  * not useable unless you're root

is this a problem from a security perspective, or a design perspective.
i.e. users should be able to chroot their processes, not to gain
security but just to be able to do things.  Or also for security?

>  * too coarse-grained

what exactly do you mean?

>  * only protects the filesystem, but not other resources (e.g., the
network)

yes, chroot doesn't make a jail, but chroot + other stuff can make a
jail, and chroot can give you the fs side for close to free (lost
performance that is)

>  * not suitable for jailing root

b/c root can break out easily, right? to jail root you need other stuff
as I said above.

> 
> > If however, one could provide even a single level of nesting, such
that
> > a chroot outside of a chroot sets the first level, and any other
chroot
> > after that sets the inner level, then even root wouldn't be able to
> > break out of the chroot (presuming it didn't bring any fd's into the
> > chroot w/ it).  
> 
> This is not quite right.  There are LOTS of other ways that root
> can break out of a chroot.

how? the class way is the fchdir, but I guess there are others, but my
brain is not seeing them right now.

> Actually, I suspect that nested chroot()s may not be needed very
> frequently, so I think a simpler approach may be simply to prevent
> a chrooted process from calling chroot() again: i.e., prevent nesting.

well, this would prevent you from using chroot w/ processes that want to
chroot (running an ftpd inside of a chroot, dont some like to chroot for
anonymous access?), I've thought about that in regards to my research
related to our zap system, and I would rather not have to do that.