From owner-svn-src-head@FreeBSD.ORG Fri Jan 31 17:28:50 2014 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0549E421; Fri, 31 Jan 2014 17:28:50 +0000 (UTC) Received: from m2.gritton.org (gritton.org [199.192.164.235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D12FC1666; Fri, 31 Jan 2014 17:28:49 +0000 (UTC) Received: from [192.168.0.34] (c-50-168-192-61.hsd1.ut.comcast.net [50.168.192.61]) (authenticated bits=0) by m2.gritton.org (8.14.7/8.14.7) with ESMTP id s0VHSg0J033456; Fri, 31 Jan 2014 10:28:42 -0700 (MST) (envelope-from jamie@freebsd.org) Message-ID: <52EBDD42.4020702@freebsd.org> Date: Fri, 31 Jan 2014 10:28:34 -0700 From: James Gritton User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Robert Watson , Alexander Leidinger Subject: Re: svn commit: r261266 - in head: sys/dev/drm sys/kern sys/sys usr.sbin/jail References: <201401291341.s0TDfDcB068211@svn.freebsd.org> <20140129134344.GW66160@FreeBSD.org> <52E906CD.9050202@freebsd.org> <20140129222210.0000711f@unknown> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, Gleb Smirnoff , src-committers@freebsd.org X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2014 17:28:50 -0000 On 1/31/2014 5:34 AM, Robert Watson wrote: > On Wed, 29 Jan 2014, Alexander Leidinger wrote: > >>> It does. I included a warning in jail.8 that this will pretty much >>> undo jail security. There are still reasons some may want to do >>> this, but it's definitely not for everyone or even most people. >> >> It only "unjails" (= basically the same security level as the >> jail-host with the added benefit of the flexibility of a jail like >> easy moving from one system to another) the jail which has this flag >> set. All other jails without the flag can not "escape" to the host. >> >> I also have to add that just setting this flag does not give access >> to the host, you also have to configure a non-default devfs rule for >> this jail (to have the devices appear in the jail). > > This is not correct: devices do not need to be delegated in devfs for > PRIV_IO to allow bypass of the Jail security model, due to sysarch() > and the Linux-emulated equivalent, which turn out direct I/O access > from a user process without use of a device node. > > Frankly, I'd like to see this backed out and not reintroduced. If it > must be retained, then it needs a much more clear warning that > enabling this feature disables Jail's security model. Don't use the > word 'obviate', instead explicitly state that root within the jail can > escape the jail. > > Robert I'll do at least the next-best thing: back it out and hope to re-introduce it. Clearly it could use some further discussion. - Jamie