From owner-freebsd-arch@FreeBSD.ORG Mon Aug 18 10:05:30 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D917E1065679 for ; Mon, 18 Aug 2008 10:05:30 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id A4A158FC19 for ; Mon, 18 Aug 2008 10:05:30 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 99A1846B06; Mon, 18 Aug 2008 05:47:12 -0400 (EDT) Date: Mon, 18 Aug 2008 10:47:12 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Kostik Belousov In-Reply-To: <20080816121049.GU1803@deviant.kiev.zoral.com.ua> Message-ID: References: <20080816111824.GL99951@hoeg.nl> <20080816121049.GU1803@deviant.kiev.zoral.com.ua> User-Agent: Alpine 1.10 (BSF 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Ed Schouten , Jille Timmermans , FreeBSD Arch Subject: Re: [Reviews requested] kern/121073: chroot for non-root users X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2008 10:05:30 -0000 On Sat, 16 Aug 2008, Kostik Belousov wrote: >> It would be great to get many reviews on this before we'd land it in the >> source tree. I've attached the patch to this email as well. Thanks! > > I think that the patch gives instant root. FreeBSD provides a rfork(2) > system call. This call allows the processes to share filedesc table, that, > among other information, contains the root of the filesystem namespace for > the process. > > So, the scenario is to rfork() a process without RFFDG flag, and then for > one of the resulting processes to perform a chroot. Now, second one has > chrooted root, but no P_NOSUGID flag set. There is a long and sordid history of vulnerability associated with the use of the chroot(2) system call in well-meaning attempts to allow users to employ it in order to improve security. Most of the lessons center on the high level of trust placed in the file system name space by UNIX applications *and* the kernel, and the unexpected implications of allowing that namespace to be manipulated by untrusted processes. I think I would generally be very conservative about making any change to behavior here, even optional change, simply because it will lead to future security advisories. More generally, I'm a bit worried by the increasing number of minor security policy variations controlled by sysctls and kernel options -- often they serve the function of optionally exposing kernel behavior not reviewed or hardened against untrusted users to use. These minor variations risk coming into conflict with application and kernel assumptions about the security model, so I think we should be very careful about adding too many. Robert N M Watson Computer Laboratory University of Cambridge