On Wed, 25 Jun 2008, Alexander Leidinger wrote:
Safe in the sense that they might, or might not, immediately panic. Not
safe in the sense that the resulting system would necessarily have the
expected or desired security properties. It wouldn't surprise me if, just
for example, allowing user mounting of nullfs from within jail allowed the
user to escape from the jail and access files outside the jail in the host
system.
I just had a look at the man page of nmount (that's what is used to mount
nullfs, and some other FS's). nmount gets the pathname (realpath). realpath
prints the path relative to the jail root, not the real name in the
jail-host. If nmount is not jail aware, then we have a meltdown. nmount is
using NDINIT/namei. If I read namei/NDINIT correctly, it picks the correct
path in a jail (else name lookups in a jail wouldn't work, right?). Any
filesystem which gets a source path also needs to use namei (AFAIK, please
correct me if I'm wrong), so this side of the mounting has the same
properties.
For FS's which don't use nmount but the old mount stuff, I don't know.
Establishing that this is not the case is fairly non-trivial and has to be
done very carefully. I would recommend extreme caution.
At least for nmount based things this would implicitly mean we have a _very_
big problem with jails (if my above analysis of the code is correct) in
other places, as the mountpoint is resolved via namei in the kernel.
Jail is carefully structured around the idea that, in general, processes
running with root privilege need very few actual privileges, they mostly just
run with the root uid and override file permissions, signal protection, and
low port number restrictions. So we scope the name spaces available to root
processes in jail and grant a few specific privileges we believe are safe.
Things like mounting file systems, raw device access, kernel module loading,
etc, are in stark contrast to this as they frob (to use the term loosely) the
substrate in which processes run: the integrity of the file system name space,
the kernel, etc. Preventing those operations is part of what gives jail its
integrity guarantees, and chipping away at those protections is inherently a
risky activity.
I don't know of any specific vulnerabilities that will open up, and I don't
have time to read the source code to find them now, but I do promise you that
if you allow arbitrary mounting of file systems in jail, you will likely run
into quite a few, simply because mounting of file systems is a sensitive
operation, modifies the file system name space that we rely on for
containment, and because file systems and the file system infrastructure have
generally not been designed with this in mind. Especially not for the idea of
an unprivileged root user.
So, per my comments, I would recommend extreme caution because the
implications are very tricky to reason about, requiring careful auditing of
source code to ensure that expected protections will continue to be enforced.
Caveat emptor. Beware the dog. Enter at your own risk. There be dragons.
Run away!
Robert N M Watson
Computer Laboratory
University of Cambridge
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-jail
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
