Date: Wed, 25 Jun 2008 18:41:51 +0200 From: Alexander Leidinger <Alexander@Leidinger.net> To: Robert Watson <rwatson@FreeBSD.org> Cc: freebsd-jail@FreeBSD.org Subject: Re: is nfs mount inside jail possible? Message-ID: <20080625184151.20404iq2r7t4iomc@webmail.leidinger.net> In-Reply-To: <20080625165505.P87282@fledge.watson.org> References: <62852722@bb.ipt.ru> <20080625173401.116369ceeiewif40@webmail.leidinger.net> <20080625175252.18342qpk0oc2zc4k@webmail.leidinger.net> <20080625165505.P87282@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Quoting Robert Watson <rwatson@FreeBSD.org> (from Wed, 25 Jun 2008 =20
16:57:17 +0100 (BST)):
> On Wed, 25 Jun 2008, Alexander Leidinger wrote:
>
>> Oh: I haven't checked if this actually works. I don't know if all =20
>> places DTRT then. Normally it should work, but you better test if =20
>> it really puts the FS in the place where you want it, that you can =20
>> mount/umount it, that "mount -v" shows the expected output on the =20
>> host and in the jail, and so on.
>>
>> Similar things can be done for =20
>> src/sys/fs/{cd9660|msdosfs|ntfs|nullfs|smbfs|udf|unionfs}. Those =20
>> are the FS's which _should_ be safe, either because they work with =20
>> untrusted data anyway, or because it's a loopback mount. But again, =20
>> I haven't tested any of them (I have them patched locally, but even =20
>> the initial testing is on my TODO list with a low priority).
>
> Safe in the sense that they might, or might not, immediately panic. =20
> Not safe in the sense that the resulting system would necessarily =20
> have the expected or desired security properties. It wouldn't =20
> surprise me if, just for example, allowing user mounting of nullfs =20
> from within jail allowed the user to escape from the jail and access =20
> 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 =20
mount nullfs, and some other FS's). nmount gets the pathname =20
(realpath). realpath prints the path relative to the jail root, not =20
the real name in the jail-host. If nmount is not jail aware, then we =20
have a meltdown. nmount is using NDINIT/namei. If I read namei/NDINIT =20
correctly, it picks the correct path in a jail (else name lookups in a =20
jail wouldn't work, right?). Any filesystem which gets a source path =20
also needs to use namei (AFAIK, please correct me if I'm wrong), so =20
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 =20
> to be done very carefully. I would recommend extreme caution.
At least for nmount based things this would implicitly mean we have a =20
_very_ big problem with jails (if my above analysis of the code is =20
correct) in other places, as the mountpoint is resolved via namei in =20
the kernel.
Bye,
Alexander.
--=20
Personnel recruiting is a triumph of hope over
experience.
http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D B0063FE7
http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D 72077137
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080625184151.20404iq2r7t4iomc>