From owner-freebsd-jail@FreeBSD.ORG Mon Sep 22 21:18:50 2008 Return-Path: Delivered-To: freebsd-jail@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D85A1106566B for ; Mon, 22 Sep 2008 21:18:50 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [91.103.162.4]) by mx1.freebsd.org (Postfix) with ESMTP id 8E0A78FC16 for ; Mon, 22 Sep 2008 21:18:50 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from localhost (localhost.codelab.cz [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 7F54419E02A; Mon, 22 Sep 2008 23:18:49 +0200 (CEST) Received: from [192.168.1.2] (r5bb235.net.upc.cz [86.49.61.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 05F0419E027; Mon, 22 Sep 2008 23:18:43 +0200 (CEST) Message-ID: <48D80BD4.8050505@quip.cz> Date: Mon, 22 Sep 2008 23:19:16 +0200 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: cz, cs, en, en-us MIME-Version: 1.0 To: glarkin@FreeBSD.org References: <20080922155111.T65801@maildrop.int.zabbadoz.net> <48D7EEA3.4040504@quip.cz> <48D7F756.9040704@FreeBSD.org> In-Reply-To: <48D7F756.9040704@FreeBSD.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-jail@freebsd.org Subject: Re: request for (security) comments on this setup X-BeenThere: freebsd-jail@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion about FreeBSD jail\(8\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2008 21:18:50 -0000 Greg Larkin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Miroslav Lachman wrote: > >>Bjoern A. Zeeb wrote: >> >>>On Mon, 22 Sep 2008, Randy Schultz wrote: >>> >>>Hi, >>> >>> >>>>I'm mounting some iSCSI storage in a jail. It's mounting in the jail >>>>via >>>>fstab.. When the jail is up and I'm logged into the jail I >>>>can cd >>>>to the mount point, r/w etc., everything seems to work. What's weird >>>>tho' is, >>>>while a df on the parent shows the partion mounted as expected, a df >>>>inside >>>>the jail shows the local disk but not the iSCSI mount. >>>>... >>>>So, my first question is what am I missing, the second is does >>>>mounting things >>>>this way into a jail pose any sort of risk for escaping the jail? >>> >>> >>>Does anything change if you do a >>> sysctl security.jail.enforce_statfs=1 >>> >>>If that's what you want you can add the following lines to >>>/etc/sysctl.conf in the base system so it is automatically set upon >>>boot: >>> >>># jails >>>security.jail.enforce_statfs=1 >> >>Have this any impact on security? >> >># sysctl -d security.jail.enforce_statfs >>security.jail.enforce_statfs: Processes in jail cannot see all mounted >>file systems >> >>For what this sysctl is implemented? >> >>Thanks >> >>Miroslav Lachman > > > Hi Miroslav, > > - From the jail(8) man page: > > security.jail.enforce_statfs > > This MIB entry determines which information processes in a jail are > able to get about mount-points. It affects the behaviour of the > following syscalls: statfs(2), fstatfs(2), getfsstat(2) and > fhstatfs(2) (as well as similar compatibility syscalls). When set > to 0, all mount-points are available without any restrictions. When > set to 1, only mount-points below the jail's chroot directory are > visible. In addition to that, the path to the jail's chroot direc- > tory is removed from the front of their pathnames. When set to 2 > (default), above syscalls can operate only on a mount-point where > the jail's chroot directory is located. > > Hope that helps, > Greg Thank you, I forgot to open jail(8) man page before posting :) If I understand it correct - it is just about what informations (about mountpoints) are visible to processes inside jail without any security impact and it is safe to use security.jail.enforce_statfs=1. Am I right? (I am sorry for maybe dump questions, but I am not kernel/OS developer and statfs, fstatfs, getfsstat did not tell me much) Miroslav Lachman