Date: Thu, 17 Mar 2016 12:54:45 +0100 From: Simon <freebsd.lists@whitewinterwolf.com> To: Miroslav Lachman <000.fbsd@quip.cz> Cc: Mark Felder <feld@freebsd.org>, James Gritton <jamie@freebsd.org>, freebsd-jail@freebsd.org, owner-freebsd-jail@freebsd.org Subject: Re: SHM objects cannot be isolated in jails, any evolution in future FreeBSD versions? Message-ID: <27abd17bc67680df02ef6d06f31d77be@whitewinterwolf.com> In-Reply-To: <56E7C926.3020201@quip.cz> References: <c1e2fc0269e9de3a653d6e47da26b026@whitewinterwolf.com> <0ad738494152d249f3bbe3b722a46bd2@gritton.org> <1457989662.568170.549069906.791C2D05@webmail.messagingengine.com> <56E7C926.3020201@quip.cz>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?27abd17bc67680df02ef6d06f31d77be>