Re: is nfs mount inside jail possible?
Quoting Robert Watson <[EMAIL PROTECTED]> (from Wed, 25 Jun 2008 17:53:36 +0100 (BST)): 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 I agree, but I put the focus on "arbitrary". What I specially did not include in the list was ufs, procfs, fdescfs and some more. UFS can cause a kernel panic if used with a bad FS image. For procfs we even recommend to not mount it in a normal system, and for others I don't know if they are robust enough. For nullfs all depends if it can break out of the jail or not. If it can not, I don't see why we should not allow to mount it in a jail. Based upon what I've read in the source, it's even easy to test. As it gets path names the kernel resolves itself, the test would be to modify mount_nullfs to not do the realpath, and test by adding some "../" into the path (ok, this is a simplified description, there are several cases which have to be tested, but it is not rocked science). For other FS it depends what they are/do and how robust they are. Wasn't there a FS-fuzzing paper a while ago which tested several FreeBSD FS for robustness? Very interesting would be the robustness for cd9660, msdosfs and udf. Those are candidates which would be interesting to use in a jail. 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! I agree with everything except the "Run away!" :) This is CS, the outcome should be deterministic... :) Bye, Alexander. -- Man who sleep in beer keg wake up stickey. http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-jail@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-jail To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: is nfs mount inside jail possible?
In response to Boris Samorodov <[EMAIL PROTECTED]>: > On Wed, 25 Jun 2008 10:37:21 -0400 Bill Moran wrote: > > > In response to Boris Samorodov <[EMAIL PROTECTED]>: > > > > > > ... nfs seems not to be jail friendly. Here is the question at > > > subject. Thanks! > > > You can NFS mount on the host, and it will be visible within the jail. > > Don't know if that helps your situation or not. > > Yep, I know it. I'd prefer to use mounts within a jail. They should be > dynamic: a process mounts it, uses and unmounts. Otherwise there will > be too many mounts... How many is too many? Why do you think that number is too many? You could run the automounter on the host. -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ [EMAIL PROTECTED] Phone: 412-422-3463x4023 ___ freebsd-jail@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-jail To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: is nfs mount inside jail possible?
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 ___ freebsd-jail@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-jail To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: is nfs mount inside jail possible?
Quoting Robert Watson <[EMAIL PROTECTED]> (from Wed, 25 Jun 2008
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
places DTRT then. Normally it should work, but you better test if
it really puts the FS in the place where you want it, that you can
mount/umount it, that "mount -v" shows the expected output on the
host and in the jail, and so on.
Similar things can be done for
src/sys/fs/{cd9660|msdosfs|ntfs|nullfs|smbfs|udf|unionfs}. Those
are the FS's which _should_ be safe, either because they work with
untrusted data anyway, or because it's a loopback mount. But again,
I haven't tested any of them (I have them patched locally, but even
the initial testing is on my TODO list with a low priority).
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.
Bye,
Alexander.
--
Personnel recruiting is a triumph of hope over
experience.
http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137
___
freebsd-jail@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-jail
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: is nfs mount inside jail possible?
On Wed, 25 Jun 2008, Alexander Leidinger wrote: ... nfs seems not to be jail friendly. Here is the question at subject. Thanks! Correct. If you are not afraid to patch the system: zfs has the JAIL flag set, you just need to do the same with nfs. To do this edit src/sys/nfsclient/nfs_vfsopts.c, search VFS_SET and change it to VFS_SET(nfs_vfsops, nfs, VFCF_NETWORK|VFCF_JAIL); I suggest to not do this with tmpfs if you do shared hosting (you don't want that strangers eat up all your physical RAM). The security implications of doing this are rather non-trivial, and should be carefully taken carefully into account. This is not a configuration I would recommend for most sites on the basis that they might not be well-equipped to reason about the indirect security consequences. There are also some potentially tricky technical elements here -- for example, some versions of FreeBSD are known to have TCP implementations that are not entirely happy with NFS running in a jail. Likewise, some of the associated services of NFS, such as rpc.statd and rpc.lockd, will not work properly with virtualization prior to 8.x (and possibly after) as they both have interesting security requirements and rely on things like each IP address being associated with at most one client. Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-jail@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-jail To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: is nfs mount inside jail possible?
On Wed, 25 Jun 2008, Alexander Leidinger wrote:
Oh: I haven't checked if this actually works. I don't know if all places
DTRT then. Normally it should work, but you better test if it really puts
the FS in the place where you want it, that you can mount/umount it, that
"mount -v" shows the expected output on the host and in the jail, and so on.
Similar things can be done for
src/sys/fs/{cd9660|msdosfs|ntfs|nullfs|smbfs|udf|unionfs}. Those are the
FS's which _should_ be safe, either because they work with untrusted data
anyway, or because it's a loopback mount. But again, I haven't tested any of
them (I have them patched locally, but even the initial testing is on my
TODO list with a low priority).
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.
Establishing that this is not the case is fairly non-trivial and has to be
done very carefully. I would recommend extreme caution.
Robert N M Watson
Computer Laboratory
University of Cambridge
___
freebsd-jail@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-jail
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: is nfs mount inside jail possible?
Quoting Alexander Leidinger <[EMAIL PROTECTED]> (from Wed, 25
Jun 2008 17:34:01 +0200):
To do this edit src/sys/nfsclient/nfs_vfsopts.c, search VFS_SET and
change it to
VFS_SET(nfs_vfsops, nfs, VFCF_NETWORK|VFCF_JAIL);
Oh: I haven't checked if this actually works. I don't know if all
places DTRT then. Normally it should work, but you better test if it
really puts the FS in the place where you want it, that you can
mount/umount it, that "mount -v" shows the expected output on the host
and in the jail, and so on.
Similar things can be done for
src/sys/fs/{cd9660|msdosfs|ntfs|nullfs|smbfs|udf|unionfs}. Those are
the FS's which _should_ be safe, either because they work with
untrusted data anyway, or because it's a loopback mount. But again, I
haven't tested any of them (I have them patched locally, but even the
initial testing is on my TODO list with a low priority).
Bye,
Alexander.
--
At the end of the semester you will recall having
enrolled in a course at the beginning of the semester
-- and never attending.
http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137
___
freebsd-jail@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-jail
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: is nfs mount inside jail possible?
Quoting Boris Samorodov <[EMAIL PROTECTED]> (from Wed, 25 Jun 2008 17:53:49 +0400): # lsvfs FilesystemRefs Flags - --- nfs4 0 network zfs 6 jail ntfs 0 ufs 4 nfs 0 network msdosfs 0 procfs 4 synthetic cd9660 0 read-only devfs5 synthetic nullfs 7 loopback fdescfs 4 synthetic - ... nfs seems not to be jail friendly. Here is the question at subject. Thanks! Correct. If you are not afraid to patch the system: zfs has the JAIL flag set, you just need to do the same with nfs. To do this edit src/sys/nfsclient/nfs_vfsopts.c, search VFS_SET and change it to VFS_SET(nfs_vfsops, nfs, VFCF_NETWORK|VFCF_JAIL); I suggest to not do this with tmpfs if you do shared hosting (you don't want that strangers eat up all your physical RAM). Bye, Alexander. -- Peers's Law: The solution to a problem changes the nature of the problem. http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-jail@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-jail To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: is nfs mount inside jail possible?
On Wed, 25 Jun 2008 10:37:21 -0400 Bill Moran wrote: > In response to Boris Samorodov <[EMAIL PROTECTED]>: > > > > ... nfs seems not to be jail friendly. Here is the question at > > subject. Thanks! > You can NFS mount on the host, and it will be visible within the jail. > Don't know if that helps your situation or not. Yep, I know it. I'd prefer to use mounts within a jail. They should be dynamic: a process mounts it, uses and unmounts. Otherwise there will be too many mounts... Bill, thanks for your try. WBR -- Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD committer, http://www.FreeBSD.org The Power To Serve ___ freebsd-jail@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-jail To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: is nfs mount inside jail possible?
In response to Boris Samorodov <[EMAIL PROTECTED]>: > > ... nfs seems not to be jail friendly. Here is the question at > subject. Thanks! You can NFS mount on the host, and it will be visible within the jail. Don't know if that helps your situation or not. -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ [EMAIL PROTECTED] Phone: 412-422-3463x4023 IMPORTANT: This message contains confidential information and is intended only for the individual named. If the reader of this message is not an intended recipient (or the individual responsible for the delivery of this message to an intended recipient), please be advised that any re-use, dissemination, distribution or copying of this message is prohibited. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. ___ freebsd-jail@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-jail To unsubscribe, send any mail to "[EMAIL PROTECTED]"
is nfs mount inside jail possible?
Hello FreeBSD jail gurus, I've found at google some advices how to do a nfs mount inside a jail. Those advices don't help me. And according to jail(8): - # uname -a FreeBSD box.bsam.ru 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Mon Jun 16 17:18:23 MSD 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/BOX amd64 # lsvfs FilesystemRefs Flags - --- nfs4 0 network zfs 6 jail ntfs 0 ufs 4 nfs 0 network msdosfs 0 procfs 4 synthetic cd9660 0 read-only devfs5 synthetic nullfs 7 loopback fdescfs 4 synthetic - ... nfs seems not to be jail friendly. Here is the question at subject. Thanks! WBR -- Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD committer, http://www.FreeBSD.org The Power To Serve ___ freebsd-jail@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-jail To unsubscribe, send any mail to "[EMAIL PROTECTED]"
