From owner-freebsd-hackers@FreeBSD.ORG Fri Dec 29 14:11:48 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E757016A407 for ; Fri, 29 Dec 2006 14:11:48 +0000 (UTC) (envelope-from wmoran@collaborativefusion.com) Received: from mx00.pub.collaborativefusion.com (mx00.pub.collaborativefusion.com [206.210.89.199]) by mx1.freebsd.org (Postfix) with ESMTP id AE13A13C478 for ; Fri, 29 Dec 2006 14:11:48 +0000 (UTC) (envelope-from wmoran@collaborativefusion.com) Received: from vanquish.pgh.priv.collaborativefusion.com (vanquish.pgh.priv.collaborativefusion.com [192.168.2.61]) (SSL: TLSv1/SSLv3,256bits,AES256-SHA) by wingspan with esmtp; Fri, 29 Dec 2006 09:01:47 -0500 id 000564C7.45951FCB.00000088 Date: Fri, 29 Dec 2006 09:01:46 -0500 From: Bill Moran To: Colin Percival Message-Id: <20061229090146.d2bc2b1c.wmoran@collaborativefusion.com> In-Reply-To: <45950CFD.5020506@freebsd.org> References: <20061229120030.3DCE316A530@hub.freebsd.org> <45950CFD.5020506@freebsd.org> Organization: Collaborative Fusion X-Mailer: Sylpheed 2.3.0 (GTK+ 2.10.6; i386-portbld-freebsd6.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: Modified version of jexec allows non-root access into jails 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: Fri, 29 Dec 2006 14:11:49 -0000 In response to Colin Percival : > Bill Moran wrote: > > http://people.collaborativefusion.com/~wmoran/code/jailme.html > > > > Feedback is appreciated. > > Be very very careful. Both chroot(2) and jail(2) can only be called by > root, and for very good reasons. Unprivileged users can create hardlinks > to files which they don't own, including setuid root binaries; but these > binaries will probably not operate correctly inside a jail of an attacker's > construction (e.g., which contains a root password of "r00tmeplz"). The > attacker can thus obtain jailed root privileges, create all the setuid > root binaries he wants, and then run them from outside of the jail to > obtain root privileges in the host machine. Interesting. I hadn't considered that possibility. > The fact that you're calling jail_attach(2) instead of jail(2) makes me > slightly less worried, but you'd still have to work very hard to convince > me that this should become part of the FreeBSD base system. Well, my ultimate goal is to get it in _only_ if it makes sense as part of the base system -- and I'm not even fully convinced of that yet. The scenario you're describing (correct me if I misunderstand) would be a user who has a normal account on the host system, but has root access inside a pre-existing jail. Said user could create a setuid binary inside the jail filesystem that would continue to be setuid in the host, and basically leads to a privilege escalation. This is possible even without the addition of the jailme program, however. Basically, any user who has root inside a jail and a normal account on the host system can easily get root permissions outside the jail. It's probably possible to prevent this by careful use of nosetuid mounted filesystems within the jail. You also describe a scenerio where a user can create a jail of his own design and give himself root inside it, thus allowing him to use the setuid trick to get root on the host as well. The place this falls down is that the user would need to already have root to create the jail in the first place. I suppose I hadn't thought this through because our setup has users with normal accounts both inside and outside the jail, and our ultimate goal is to keep these users from ever having or needing root access in either place. I'll wrap it up and submit it as a port. It seems like most of the current jail utilities start out as ports anyway, so that seems to be a good path to determine whether or not it's a proper fit for the base system. If not, it can just stay a port for anyone who finds it useful. -- Bill Moran Collaborative Fusion Inc.