svn commit: r261266 - in head: sys/dev/drm sys/kern sys/sys usr.sbin/jail
James Gritton
jamie at freebsd.org
Sat Feb 1 01:28:37 UTC 2014
On 1/31/2014 2:30 PM, Alexander Leidinger wrote:
> On Fri, 31 Jan 2014 12:34:48 +0000 (GMT)
> Robert Watson <rwatson at FreeBSD.org> 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.
I'd like to re-submit the patch with only the documentation changed
(unless someone knows of something that would accomplish the same
goals with different code). But I'll run it by secteam@ first, and
abide by the consensus there.
- Jamie
More information about the svn-src-all
mailing list