From owner-svn-src-all@FreeBSD.ORG Sat Feb 1 01:28:37 2014 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0392AAEC; Sat, 1 Feb 2014 01:28:37 +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 B69741D30; Sat, 1 Feb 2014 01:28:36 +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 s111SZZH057284; Fri, 31 Jan 2014 18:28:35 -0700 (MST) (envelope-from jamie@freebsd.org) Message-ID: <52EC4DBB.50804@freebsd.org> Date: Fri, 31 Jan 2014 18:28:27 -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: Alexander Leidinger , Robert Watson 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> <20140131223011.0000163b@unknown> In-Reply-To: <20140131223011.0000163b@unknown> 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-all@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Feb 2014 01:28:37 -0000 On 1/31/2014 2:30 PM, Alexander Leidinger wrote: > On Fri, 31 Jan 2014 12:34:48 +0000 (GMT) > 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. > > Ok, then it is just the non-default flag, not the additional devfs part. > > I agree with your other post that we are better of to document better > what it means if an admin allows kmem access for a specific jail. I second the documentation route. Yes, it's true that this option makes a totally insecure jail - at least one lacking the expected jail security additions. But I think that while security is one of the primary purposes of jails, it's not the only purpose. It should be possible to have a trusted "master jail" that still takes advantage of the encapsulation while allowing otherwise unsupported features such as a desktop. The distinction of whether certain devices are required to break out of a jail with allow.kmem is something of a red herring - the fact is that anyone who wants this level of access is going to have the devices in place anyway. I suppose "obviate" wasn't the best word for the situation. Maybe something that starts with "WARNING: ..." is in order. I'd like to re-submit the patch with only the documentation changed (unless someone knows of something that would accomplish the same goals with different code). But I'll run it by secteam@ first, and abide by the consensus there. - Jamie