From owner-freebsd-stable@FreeBSD.ORG Fri Jan 12 04:29:57 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5844216A40F for ; Fri, 12 Jan 2007 04:29:57 +0000 (UTC) (envelope-from cperciva@freebsd.org) Received: from pd5mo3so.prod.shaw.ca (shawidc-mo1.cg.shawcable.net [24.71.223.10]) by mx1.freebsd.org (Postfix) with ESMTP id 2C7E313C43E for ; Fri, 12 Jan 2007 04:29:57 +0000 (UTC) (envelope-from cperciva@freebsd.org) Received: from pd5mr3so.prod.shaw.ca (pd5mr3so-qfe3.prod.shaw.ca [10.0.141.144]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0JBQ00DYRN2QUB30@l-daemon> for freebsd-stable@freebsd.org; Thu, 11 Jan 2007 21:28:02 -0700 (MST) Received: from pn2ml7so.prod.shaw.ca ([10.0.121.151]) by pd5mr3so.prod.shaw.ca (Sun Java System Messaging Server 6.2-7.05 (built Sep 5 2006)) with ESMTP id <0JBQ004DYN2PEIL1@pd5mr3so.prod.shaw.ca> for freebsd-stable@freebsd.org; Thu, 11 Jan 2007 21:28:02 -0700 (MST) Received: from hexahedron.daemonology.net ([24.82.18.31]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with SMTP id <0JBQ00J6YN2OI2F2@l-daemon> for freebsd-stable@freebsd.org; Thu, 11 Jan 2007 21:28:01 -0700 (MST) Received: (qmail 68154 invoked from network); Fri, 12 Jan 2007 04:29:25 +0000 Received: from unknown (HELO ?127.0.0.1?) (127.0.0.1) by localhost with SMTP; Fri, 12 Jan 2007 04:29:25 +0000 Date: Thu, 11 Jan 2007 20:29:25 -0800 From: Colin Percival In-reply-to: <45A70026.2010601@h3q.com> To: Philipp Wuensche Message-id: <45A70EA5.1010402@freebsd.org> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7bit X-Enigmail-Version: 0.94.0.0 References: <200701111841.l0BIfWOn015231@freefall.freebsd.org> <45A6DB76.40800@freebsd.org> <45A70026.2010601@h3q.com> User-Agent: Thunderbird 1.5.0.9 (X11/20061227) Cc: freebsd-security@freebsd.org, freebsd-stable@freebsd.org Subject: Re: HEADS UP: Re: FreeBSD Security Advisory FreeBSD-SA-07:01.jail X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jan 2007 04:29:57 -0000 Philipp Wuensche wrote: > Colin Percival wrote: >> In the end we opted to reduce functionality (the jail startup process is >> no longer logged to /var/log/console.log inside the jail) > > Thats a bummer, when Dirk showed me this problem the first time my ideas > for fixing this problem without losing the functionality where changing > flags on the file so it can't be removed or/and checking if it is really > a file or a symlink instead. Of course you have to check if /var/log has > symlinked parent directories before. > > First is quite problematic and setting flags on file is something > scripts which create a jail in the first place probably have to bother > with so option two would be my approach. Did I miss a possible problem > with that idea? Assuming that "option two" means "use file flags to make sure that the host can write to the jailed /var/log/console.log securely", setting the sunlnk flag on the jail's /var and /var/log would probably break many jails -- for one thing, log rotation would become impossible. Then there's the problem of systems with chflags_allowed=1... >> (filesystems which are mounted via per-jail >> fstab files should not be mounted on symlinks -- if you do this, adjust your >> fstab files to give the real, non-symlinked, path to the mount point), and > > If I understand the patch correct it checks recursive all parent > directories of a mountpoint in is_symlinked_mountpoint(), wouldn't it be > better to just check for a symlinked parent directory up to and not > including ${_rootdir}? This option never occurred to me; I _think_ it would work, but it would require canonicalizing the jail root path... even if I had thought of this, I might have decided to avoid this on the basis that complexity == bugs == bad for security patches. Colin Percival