Date: Mon, 10 Feb 2014 17:24:09 -0800 From: Adrian Chadd <adrian@freebsd.org> To: James Gritton <jamie@freebsd.org> Cc: "src-committers@freebsd.org" <src-committers@freebsd.org>, Doug Ambrisko <ambrisko@ambrisko.com>, John Baldwin <jhb@freebsd.org>, "svn-src-all@freebsd.org" <svn-src-all@freebsd.org>, Gleb Smirnoff <glebius@freebsd.org>, Robert Watson <rwatson@freebsd.org>, "svn-src-head@freebsd.org" <svn-src-head@freebsd.org>, Alexander Leidinger <Alexander@leidinger.net> Subject: Re: svn commit: r261266 - in head: sys/dev/drm sys/kern sys/sys usr.sbin/jail Message-ID: <CAJ-VmokaKL8HWEQCszAJnY1XQ6h_%2Byfpjy91r=7b2cfgEJFJHQ@mail.gmail.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
On 10 February 2014 17:07, James Gritton <jamie@freebsd.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-VmokaKL8HWEQCszAJnY1XQ6h_%2Byfpjy91r=7b2cfgEJFJHQ>