From owner-freebsd-doc@FreeBSD.ORG Wed Sep 4 15:22:42 2013 Return-Path: Delivered-To: freebsd-doc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id DAF2BE91; Wed, 4 Sep 2013 15:22:42 +0000 (UTC) (envelope-from galtsev@kicp.uchicago.edu) Received: from cosmo.uchicago.edu (cosmo.uchicago.edu [128.135.52.97]) by mx1.freebsd.org (Postfix) with ESMTP id 73D3F2B4F; Wed, 4 Sep 2013 15:22:42 +0000 (UTC) Received: by cosmo.uchicago.edu (Postfix, from userid 48) id 0342ACB8C92; Wed, 4 Sep 2013 10:22:35 -0500 (CDT) Received: from 128.135.70.2 (SquirrelMail authenticated user valeri) by cosmo.uchicago.edu with HTTP; Wed, 4 Sep 2013 10:22:35 -0500 (CDT) Message-ID: <23025.128.135.70.2.1378308155.squirrel@cosmo.uchicago.edu> In-Reply-To: <2169287.FiyytKgDHO@gizmo.nevosoft.local> References: <2169287.FiyytKgDHO@gizmo.nevosoft.local> Date: Wed, 4 Sep 2013 10:22:35 -0500 (CDT) Subject: Re: handbook chapter for jail best practices needs for security remark From: "Valeri Galtsev" To: "olevole" User-Agent: SquirrelMail/1.4.8-5.el5.centos.7 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: freebsd-doc@freebsd.org, freebsd-jail@freebsd.org X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: galtsev@kicp.uchicago.edu List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 15:22:42 -0000 Nice observation! Yet: for that to work both rw and ro portions mounted inside the same jail have to be on the same filesystem. For hardlinks to work, both parts of hardlink ("source" and "destination") should be on the same filesystem. Even though I'm not considering myself an expert in security, I will never have ro and rw filesystem (mounted inside the same jail) to live physically on the same filesystem... That said, I'm never using ezjail or some other scripts to lay out jails for me. So, apart from making a warning in handbook (which is always instructive and educational!), one may need to audit jail creating scripts. I'm certain, they are good about that (and my great respects to authors!), but taking an extra look at specific thing never hurts. Thanks. Valeri On Wed, September 4, 2013 4:40 am, olevole wrote: > Mounting directory via nullfs when RW part mounted above RO from one > filesystem > is insecure for RO location, > because it allows you to edit a file by hardlink on RO place, due to the > fact > that the files have one inode. > > For example (by root user): > > % mkdir /usr/chroot > % bsdinstall jail /usr/chroot > % mount_nullfs -oro /bin /usr/chroot/bin > % mkdir /rw > % mount_nullfs /rw /usr/chroot/root > > % chroot /usr/chroot > % touch /bin/date > touch: /bin/date: Read-only file system > > % cd ~ > % ln /bin/date > % ls -i /bin/date /root/date > 58182 /bin/date 58182 /root/date > > (open /root/date in vi editor and change something) > % vi date > dd > :wq! > > (logout from chroot) > % exit > > (now /bin/date is corrupted) > % /bin/date > /bin/date: Exec format error. Binary file not executable. > > Such scheme when the RW data is overlaid above RO data is popular for jail > hosting and described in Handbook: > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails-application.html > > Perhaps it is worth mentioning in the article about > the need to separate base to cross-device storage or place it on a > read-only > system. > > _______________________________________________ > freebsd-jail@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-jail > To unsubscribe, send any mail to "freebsd-jail-unsubscribe@freebsd.org" > ++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++