From owner-svn-src-head@FreeBSD.ORG Wed Feb 5 19:28:23 2014 Return-Path: Delivered-To: svn-src-head@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 33D1E2E7; Wed, 5 Feb 2014 19:28:23 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E18BA1E23; Wed, 5 Feb 2014 19:28:22 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id BCC99B924; Wed, 5 Feb 2014 14:28:20 -0500 (EST) From: John Baldwin To: Doug Ambrisko Subject: Re: svn commit: r261266 - in head: sys/dev/drm sys/kern sys/sys usr.sbin/jail Date: Wed, 05 Feb 2014 14:05:29 -0500 Message-ID: <2362081.WrjYmKeYu9@ralph.baldwin.cx> User-Agent: KMail/4.10.5 (FreeBSD/10.0-STABLE; KDE/4.10.5; amd64; ; ) In-Reply-To: <20140203235336.GA46006@ambrisko.com> References: <201401291341.s0TDfDcB068211@svn.freebsd.org> <52EC4DBB.50804@freebsd.org> <20140203235336.GA46006@ambrisko.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 05 Feb 2014 14:28:20 -0500 (EST) Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, Gleb Smirnoff , Robert Watson , James Gritton , svn-src-head@freebsd.org, Alexander Leidinger 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: Wed, 05 Feb 2014 19:28:23 -0000 On Monday, February 03, 2014 03:53:36 PM Doug Ambrisko wrote: > 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. There are certainly use cases for a "job" (imagine in a compute cluster). Jails have some nice properties in that you can wait6/waitid for a jail, you can forcefully kill an entire jail, and you can apply resource limits to a jail collectively. I think having a "kmem" flag for jails is a hack and not the right approach. It does make a jail useless security-wise, but by masquerading as a flag, it implies that it is only partially violating security which gives a false sense of security. A short term solution that would permit non-security jails without having to do the longer term work that Robert would like might be to add a new per-jail flag that in effect means "no security at all". You would then modify one place (prison_priv_check() in kern_jail.c) to treat a jail with this flag set as if it wasn't jailed at all. This would clearly communicate to a user what they were doing by enabling this flag (jail --root-me-please), and it would also avoid future proliferation of new flags to add more optional and obscure holes in jails. -- John Baldwin