From owner-svn-src-all@FreeBSD.ORG Tue Feb 11 01:24:11 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 41344583; Tue, 11 Feb 2014 01:24:11 +0000 (UTC) Received: from mail-qa0-x22a.google.com (mail-qa0-x22a.google.com [IPv6:2607:f8b0:400d:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7F161107B; Tue, 11 Feb 2014 01:24:10 +0000 (UTC) Received: by mail-qa0-f42.google.com with SMTP id k4so10855300qaq.15 for ; Mon, 10 Feb 2014 17:24:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=ijrHcRlXr5iRN8EN5k1+NTjZIXdUUkgzyFu6k6PW8BY=; b=LnPRD9Kh6gfsYHiq+EgwCsfdsy7Kd64Xo4zFJYqklyfjDHS3DNKaAiTFG5pK+HjaiF PU3Pfo/lIEnFn+uVIs42weJxkHQZaTuu9IbTXY0GYVJ4gQzbkDpkJTiTBf1lG74HhfCn +cXOFhsAOdDjDiR+RA94rEKfOpNUEqSpEiTqqMWikg9broPGMpy5zd5dnOX9tKNzfE6N QZVRcXRnQ71t7slLCTlo2ffmXr8/DpLym8c3zAl2xSV7/mxXsuSPsGTbbsooYx9Alvji CdCfmpRttnsyWuOFc66KAiSo2S2+RDXFmG3t2Ro6NU1flBx9u18rYNqnlg6yzjoszN7W pJMg== MIME-Version: 1.0 X-Received: by 10.140.96.180 with SMTP id k49mr49332355qge.4.1392081849559; Mon, 10 Feb 2014 17:24:09 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.52.8 with HTTP; Mon, 10 Feb 2014 17:24:09 -0800 (PST) In-Reply-To: <52F977D9.5010200@freebsd.org> References: <201401291341.s0TDfDcB068211@svn.freebsd.org> <52EC4DBB.50804@freebsd.org> <20140203235336.GA46006@ambrisko.com> <2362081.WrjYmKeYu9@ralph.baldwin.cx> <52F977D9.5010200@freebsd.org> Date: Mon, 10 Feb 2014 17:24:09 -0800 X-Google-Sender-Auth: hbTlafeXwKBaILra1-Z5chYNwVU Message-ID: Subject: Re: svn commit: r261266 - in head: sys/dev/drm sys/kern sys/sys usr.sbin/jail From: Adrian Chadd To: James Gritton Content-Type: text/plain; charset=ISO-8859-1 Cc: "src-committers@freebsd.org" , Doug Ambrisko , John Baldwin , "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: Tue, 11 Feb 2014 01:24:11 -0000 On 10 February 2014 17:07, James Gritton wrote: > 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." I'd rather it stay a patch. IMHO the only viable solution is to create a sandboxable API for this DRI/IO-MMU stuff to, well, DRI via. So hm. Can you actually run clients in different jails, but have them access the same DRI window(s)? Or does running a client in a jail force it to go all over the socket(s) and not via DRI? -a