SHM objects cannot be isolated in jails, any evolution in future FreeBSD versions?

[Miroslav Lachman]

James Gritton wrote on 03/23/2016 00:25:
> On 2016-03-17 05:54, Simon wrote:
>> Le 2016-03-15 09:34, Miroslav Lachman a écrit :
>>> Mark Felder wrote on 03/14/2016 22:07:
>>>>
>>>>
>>>> On Sat, Mar 12, 2016, at 11:42, James Gritton wrote:
>>>>> On 2016-03-12 04:05, Simon wrote:
>>>>>> The shm_open()(2) function changed since FreeBSD 7.0: the SHM objects
>>>>>> path are now uncorrelated from the physical file system to become
>>>>>> just
>>>>>> abstract objects. Probably due to this, the jail system do not
>>>>>> provide
>>>>>> any form of filtering regarding shared memory created using this
>>>>>> function. Therefore:
>>>>>>
>>>>>> - Anyone can create unauthorized communication channels between
>>>>>> jails,
>>>>>> - Users with enough privileges in any jail can access and modify any
>>>>>> SHM objects system-wide, ie. shared memory objects created in any
>>>>>> other jail and in the host system.
>>>>>>
>>>>>> I've seen a few claims that SHM objects were being handled
>>>>>> differently
>>>>>> whether they were created inside or outside a jail. However, I tested
>>>>>> on FreeBSD 10.1 and 9.3 but found no evidence of this: both version
>>>>>> were affected by the same issue.
>>>>>>
>>>>>> A reference of such claim:
>>>>>> https://lists.freebsd.org/pipermail/freebsd-ports-bugs/2015-July/312665.html
>>>>>>
>>>>>>
>>>>>> My initial post on FreeBSD forum discussing the issue with more
>>>>>> details: https://forums.freebsd.org/threads/55468/
>>>>>>
>>>>>> Currently, there does not seem to be any way to prevent this.
>>>>>>
>>>>>> I'm therefore wondering if there are any concrete plans to change
>>>>>> this
>>>>>> situation in future FreeBSD versions? Be able to block the currently
>>>>>> free inter-jail SHM-based communication seems a minimum, however such
>>>>>> setting would also most likely prevent SHM-based application to work.
>>>>>>
>>>>>> Using file based SHM objects in jails seemed a good ideas but it does
>>>>>> not seem implemented this way, I don't know why. Is this planned, or
>>>>>> are there any greater plans ongoing also involving IPC's similar
>>>>>> issue?
>>>>>
>>>>> There are no concrete plans I'm aware of, but it's definitely a thing
>>>>> that should be done.  How about filing a bug report for it?  You've
>>>>> already got a good write-up of the situation.
>>>>>
>>>>
>>>> Both this and SYSV IPC jail support[1] are badly needed.
>>>>
>>>> [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=48471
>>>
>>> Yes, it is very sad that original patch was not commited, nor
>>> commented or improved by core developers for long 13 years. I am not
>>> 100% sure but I thing there was some patch from PJD for SysV IPC too.
>>> There were EclipseBSD with resource limits in times of FreeBSD 3.4 and
>>> there is FreeVPS for 6.x with virtualized IPC...
>>>
>>> So I really hope SysV IPC aware jails will become reality soon.
>>>
>>> Miroslav Lachman
>>
>> Hi everyone,
>>
>> Odd thing, I've seen that the very first exchanges which opened this
>> mailing list back in 2007 precisely discussed IPC isolation in Jail
>> and some work already done in the Jail2 project part of the now
>> abandoned FreeVPS project. At that time IPC virtualization was
>> qualified as an easy job:
>>
>>> As say about SYSV IPC stuff you say about only virtualization? or
>>> also about limits? "virtualization" is easy, but for limits - need more
>>> work
>> (https://lists.freebsd.org/pipermail/freebsd-jail/2007-May/000004.html)
>>
>> We have now come full circle :).
>>
>> As per the SHM objects issue, I've now filled a new bug #208082:
>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=208082
>>
>> I explain in the bug description why it may be different than the
>> already existing bug #48471 covering SysV IPC.
>>
>> Le 2016-03-17 01:10, Dewayne Geraghty a écrit :
>>> PS We don't want/need the complexity (or performance hit) associated
>>> with v* additions when a well thought out (simple) jail does the task
>>> very nicely :)
>>
>> I agree, the main advantage of jails and other lightweight containers
>> is precisely their lightness.
>>
>> Regards,
>> Simon.
>
> I've put a diff on the bug report (Bug 208082), for the shm objects, and
> also for ksem and mqueue which have the same problems.  Any review is
> welcome :-).
>
> SYSV IPC is a separate issue.  I'm following up with bz about my memory
> of hearing there's something vimage-related there, and if there isn't I
> can jump into that one as well (I actually have some work already done
> with it, so it just needs a little more).

I am more interested in SysV IPC (needed to run PostgreSQL in jails) but 
working SHM is good starting point. I really appreciate all your work on 
improving jails!

Thank you for this great news :)

Miroslav Lachman