Date: Mon, 18 Aug 2008 10:47:12 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Kostik Belousov <kostikbel@gmail.com> Cc: Ed Schouten <ed@80386.nl>, Jille Timmermans <jille@quis.cx>, FreeBSD Arch <freebsd-arch@freebsd.org> Subject: Re: [Reviews requested] kern/121073: chroot for non-root users Message-ID: <alpine.BSF.1.10.0808181034000.9010@fledge.watson.org> In-Reply-To: <20080816121049.GU1803@deviant.kiev.zoral.com.ua> References: <20080816111824.GL99951@hoeg.nl> <20080816121049.GU1803@deviant.kiev.zoral.com.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.1.10.0808181034000.9010>