From owner-svn-src-head@FreeBSD.ORG Tue Feb 11 01:07:58 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 7DDC5243; Tue, 11 Feb 2014 01:07:58 +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 4F3D51E1C; Tue, 11 Feb 2014 01:07:57 +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 s1B17hHn006615; Mon, 10 Feb 2014 18:07:43 -0700 (MST) (envelope-from jamie@freebsd.org) Message-ID: <52F977D9.5010200@freebsd.org> Date: Mon, 10 Feb 2014 18:07:37 -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: John Baldwin , Doug Ambrisko Subject: Re: svn commit: r261266 - in head: sys/dev/drm sys/kern sys/sys usr.sbin/jail References: <201401291341.s0TDfDcB068211@svn.freebsd.org> <52EC4DBB.50804@freebsd.org> <20140203235336.GA46006@ambrisko.com> <2362081.WrjYmKeYu9@ralph.baldwin.cx> In-Reply-To: <2362081.WrjYmKeYu9@ralph.baldwin.cx> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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-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: Tue, 11 Feb 2014 01:07:58 -0000 On 2/5/2014 12:05 PM, John Baldwin wrote: > 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. So is it worthwhile to add a new jail parameter called "insecure" (or somesuch)? That way you could easily add the encapsulation without any of the security. The other vibe I'm getting is not to do anything. Either way, it sounds like the Xorg-enabling patch will remain a patch - not seeing a lot of buy-in here. I'm not against more optional and obscure holes if they have a use; I just call that "a fine-grained capabilities model." - Jamie