svn commit: r261266 - in head: sys/dev/drm sys/kern sys/sys usr.sbin/jail

[Adrian Chadd]

On 10 February 2014 17:07, James Gritton <jamie at 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