Date: Wed, 25 Jun 2008 17:53:36 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Alexander Leidinger <Alexander@Leidinger.net> Cc: freebsd-jail@FreeBSD.org Subject: Re: is nfs mount inside jail possible? Message-ID: <20080625174425.W87282@fledge.watson.org> In-Reply-To: <20080625184151.20404iq2r7t4iomc@webmail.leidinger.net> References: <62852722@bb.ipt.ru> <20080625173401.116369ceeiewif40@webmail.leidinger.net> <20080625175252.18342qpk0oc2zc4k@webmail.leidinger.net> <20080625165505.P87282@fledge.watson.org> <20080625184151.20404iq2r7t4iomc@webmail.leidinger.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080625174425.W87282>