From owner-freebsd-hackers@FreeBSD.ORG Thu May 19 17:54:17 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A14CC106566B for ; Thu, 19 May 2011 17:54:17 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) Received: from mail.ambrisko.com (mail.ambrisko.com [64.174.51.43]) by mx1.freebsd.org (Postfix) with ESMTP id 599378FC14 for ; Thu, 19 May 2011 17:54:17 +0000 (UTC) X-Ambrisko-Me: Yes Received: from server2.ambrisko.com (HELO internal.ambrisko.com) ([192.168.1.2]) by ironport.ambrisko.com with ESMTP; 19 May 2011 10:25:30 -0700 Received: from ambrisko.com (localhost [127.0.0.1]) by internal.ambrisko.com (8.14.4/8.14.4) with ESMTP id p4JHP0Tf023592; Thu, 19 May 2011 10:25:00 -0700 (PDT) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.14.4/8.14.4/Submit) id p4JHOxBJ023590; Thu, 19 May 2011 10:24:59 -0700 (PDT) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <201105191724.p4JHOxBJ023590@ambrisko.com> In-Reply-To: To: Arnaud Lacombe Date: Thu, 19 May 2011 10:24:59 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL124d (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Cc: Alexander Leidinger , Pawel Jakub Dawidek , "freebsd-hackers@freebsd.org" Subject: Re: NFS mount inside jail fails X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2011 17:54:17 -0000 Arnaud Lacombe writes: | Hi, | | On Wed, May 18, 2011 at 10:03 AM, Pawel Jakub Dawidek 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 | >> 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.