From owner-freebsd-hackers@FreeBSD.ORG Thu May 19 02:37:25 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 AE66E106566C; Thu, 19 May 2011 02:37:25 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 0B4E58FC13; Thu, 19 May 2011 02:37:24 +0000 (UTC) Received: by iyj12 with SMTP id 12so2552437iyj.13 for ; Wed, 18 May 2011 19:37:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=uACOKuWyB7QLHEpPIdwWzRaeZhHJSGAp6u4+9xCY1qg=; b=qXfHPDHwibAbfwyZVUTZeuxk8NQQP3UDiycW/232jxS7kgEkMy4frzWYl03eEYNTpI K8oKBArVpJvRGXx2GSwpv9ePNQQGC2gPcn77GS3fWVa+CKgg0YcKS0cen7BaKF4t3e1w fjChzrJ2NjD+MYad//Qc3fgAZyYidgwF0v6XU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=OP0J32QDlxO31+jSs1yGmMqmLb+maHdmvZ+sgpHPqi6Ud6k93+dT2+/TOc6kX11JIV e2Enr4Ed1OTnim6o8cSNE6aMFXZU3udrOMcnuF8SJzTmmJSW/BJIiz9DcZeBdtE2SrJF mRks7GBQeoGMlIZSEvec98Y7QCV8vja6jTwow= MIME-Version: 1.0 Received: by 10.43.131.70 with SMTP id hp6mr3096643icc.210.1305772644351; Wed, 18 May 2011 19:37:24 -0700 (PDT) Received: by 10.42.177.10 with HTTP; Wed, 18 May 2011 19:37:24 -0700 (PDT) In-Reply-To: <20110518140326.GD1867@garage.freebsd.pl> References: <1305662200.2633.11.camel@hitfishpass-lx.corp.yahoo.com> <20110517221712.00006e91@unknown> <20110518140326.GD1867@garage.freebsd.pl> Date: Wed, 18 May 2011 22:37:24 -0400 Message-ID: From: Arnaud Lacombe To: Pawel Jakub Dawidek Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Alexander Leidinger , "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 02:37:25 -0000 Hi, On Wed, May 18, 2011 at 10:03 AM, Pawel Jakub Dawidek wro= te: > 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. =A0User wanted to NFS mount a dir inside= a >> > jail. =A0After I groaned about the security implication of this, I not= ed >> > that there is a sysctl that looks like it should allow this. =A0Namely= , >> > security.jail.mount_allowed. =A0I noted that setting this follows a pa= th >> > 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. =A0because 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. - Arnaud > There are other file systems that don't require access to raw storage > for the user doing the mount and chances are they are safe to mount from > within a jail, like ZFS (user can have access to ZFS datasets, but don't > need access to ZFS pool), NFS, SMBFS, NULLFS, UNIONFS, PROCFS, FDESCFS, > etc. I added VFCF_JAIL flag, so there is general mechanism to mark file > systems as jail-friendly, but back then I only needed it for ZFS. >