From owner-freebsd-security@FreeBSD.ORG Thu Jul 19 18:00:00 2007 Return-Path: X-Original-To: freebsd-security@freebsd.org Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 61E6316A400 for ; Thu, 19 Jul 2007 18:00:00 +0000 (UTC) (envelope-from pieter@thedarkside.nl) Received: from mail.thelostparadise.com (aberdeen.thelostparadise.com [193.202.115.174]) by mx1.freebsd.org (Postfix) with ESMTP id 2B53513C4AA for ; Thu, 19 Jul 2007 17:59:59 +0000 (UTC) (envelope-from pieter@thedarkside.nl) Received: from [192.168.1.10] (s55915f73.adsl.wanadoo.nl [85.145.95.115]) by mail.thelostparadise.com (Postfix) with ESMTP id AD53D61C1F; Thu, 19 Jul 2007 19:35:11 +0200 (CEST) Message-ID: <469FA0D1.7000304@thedarkside.nl> Date: Thu, 19 Jul 2007 19:35:13 +0200 From: Pieter de Boer User-Agent: Thunderbird 2.0.0.4 (X11/20070707) MIME-Version: 1.0 To: Stef Walter References: <20070717032204.09BA8D4F8E@mx.npubs.com> In-Reply-To: <20070717032204.09BA8D4F8E@mx.npubs.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-security@freebsd.org Subject: Re: kern.chroot_allow_open_directories X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2007 18:00:00 -0000 Stef Walter wrote: > The chroot(2) man page describes a sysctl called > 'kern.chroot_allow_open_directories' which controls whether a process > can chroot() and is already subject to the chroot() syscall. > > It seems that this sysctl can be trivially changed from within a > chroot'd process (ie: if that process has superuser privileges). > > Is this sysctl meant to prevent breaking out of a chroot? Or am I > missing the point of 'kern.chroot_allow_open_directories'? > If the sysctl was set to 0 at the moment chroot() was called, then the chroot() would have failed if the calling process had open directories (that's what the sysctl is meant to do, if I'm understanding the source right). If directories weren't open, the chroot() would work, but the process would obviously not be able to open directories outside the chroot after that, even if you'd set the sysctl to 1. As I see it, there's no problem here, but could be wrong; chroot() is tricky afaik.. -- Pieter