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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/