NFS mount inside jail fails

[Doug Ambrisko]

Arnaud Lacombe writes:
| Hi,
| 
| On Wed, May 18, 2011 at 10:03 AM, Pawel Jakub Dawidek <pjd at freebsd.org> wrote:
| > On Tue, May 17, 2011 at 10:17:12PM +0200, Alexander Leidinger wrote:
| >> On Tue, 17 May 2011 12:56:40 -0700 Sean Bruno <seanbru at yahoo-inc.com>
| >> wrote:
| >>
| >> > Silly thing I ran into today. ?User wanted to NFS mount a dir inside a
| >> > jail. ?After I groaned about the security implication of this, I noted
| >> > that there is a sysctl that looks like it should allow this. ?Namely,
| >> > security.jail.mount_allowed. ?I noted that setting this follows a path
| >> > that *should* have allowed this silly thing to happen, except that the
| >> > credentials in the nfsclient were not setup correctly.
| >>
| >> As you noticed, this is supposed to allow to mount inside a jail, IF
| >> the FS you want to mount is marked as secure/safe to do so. Nearly no
| >> FS is marked as such, as nobody wants to guarantee that it is safe
| >> (root in a jail should not be able to panic a system by trying to
| >> mount a corrupt/malicious FS-image) and secure (not possible to get
| >> elevated access/privileges).
| >>
| >> For NFS there is theoretically the problem that the outgoing address on
| >> requests could be the one of the physical host instead of the IP of the
| >> jail. If this is true in practice, I do not know. This could be
| >> the reason why NFS is not marked with VFCF_JAIL.
| >
| > It is not marked with VFCF_JAIL, because I just had no time to audit
| > that it is safe. It might be safe in theory.
| >
| > There are some file systems types that can't be securely mounted within
| > a jail no matter what, like UFS, MSDOFS, EXTFS, XFS, REISERFS, NTFS,
| > etc. ?because the user mounting it has access to raw storage and can
| > corrupt it in a way that it will panic entire system.
| 
| This should at least be configurable somehow for people who are using
| jails for separation and do not care about security. I'd expect that
| security decision whether or not to allow something is user relevant,
| not developer relevant.

Yes, we need to look at having sysctl's to enable more permissive options
when jails/vimage are not used to isolate users from systems but other
uses.  I'm now starting to use vimage in 8.2 and -current to make my
"host" trivial but do all of the "smarts" in a vimage.  This lets me spin
up a new image quickly and migrate.  One challenge is wireless.  You can't 
run wpa_supplicant in a vimage.  I can understand whey the ioctls are blocked 
since you could have a wireless instance in one jail and another instance in 
another jail.  However, to manage that instance can require the ioctls and 
the host doesn't have access to it anymore either.  Running an X server in a 
vimage has some issues.  Most are pretty easy to over-come.

Maybe it might be good to have a sysctl to not do any checks at all so it
acts like a chroot like security.jail.param.allow.all?

Doug A.