From owner-svn-src-all@FreeBSD.ORG Mon Feb 3 23:53:43 2014 Return-Path: Delivered-To: svn-src-all@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 C84CFCA9; Mon, 3 Feb 2014 23:53:43 +0000 (UTC) Received: from mail.ambrisko.com (mail.ambrisko.com [70.91.206.90]) by mx1.freebsd.org (Postfix) with ESMTP id 7D3F515FB; Mon, 3 Feb 2014 23:53:43 +0000 (UTC) X-Ambrisko-Me: Yes Received: from server2.ambrisko.com (HELO internal.ambrisko.com) ([192.168.1.2]) by ironport.ambrisko.com with ESMTP; 03 Feb 2014 15:58:07 -0800 Received: from ambrisko.com (localhost [127.0.0.1]) by internal.ambrisko.com (8.14.4/8.14.4) with ESMTP id s13NrbqP079135; Mon, 3 Feb 2014 15:53:37 -0800 (PST) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.14.4/8.14.4/Submit) id s13NraJf079133; Mon, 3 Feb 2014 15:53:36 -0800 (PST) (envelope-from ambrisko) Date: Mon, 3 Feb 2014 15:53:36 -0800 From: Doug Ambrisko To: James Gritton Subject: Re: svn commit: r261266 - in head: sys/dev/drm sys/kern sys/sys usr.sbin/jail Message-ID: <20140203235336.GA46006@ambrisko.com> References: <201401291341.s0TDfDcB068211@svn.freebsd.org> <20140129134344.GW66160@FreeBSD.org> <52E906CD.9050202@freebsd.org> <20140129222210.0000711f@unknown> <20140131223011.0000163b@unknown> <52EC4DBB.50804@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52EC4DBB.50804@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: src-committers@FreeBSD.org, svn-src-all@FreeBSD.org, Gleb Smirnoff , Robert Watson , svn-src-head@FreeBSD.org, Alexander Leidinger 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: Mon, 03 Feb 2014 23:53:44 -0000 On Fri, Jan 31, 2014 at 06:28:27PM -0700, James Gritton wrote: | 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. It's unfortunate that vimage requires jail. I want to use vimage but not have the security restrictions of a jail. To do this I patched jail to basically let everything through. It would be nice to be able to run jail in an insecure mode which I understand is a contradition. I do use the jail infrastructure to set the uname*/getosreldate so that a specific jail thinks it is FreeBSD version blah. Then I can ssh into that jail and pkg_add things, make ports etc. I use this on my laptop running current on the base. My other jails run various versions of FreeBSD. I don't care about security in this case. Thanks, Doug A.