From owner-freebsd-jail@freebsd.org Mon Mar 14 21:07:45 2016 Return-Path: Delivered-To: freebsd-jail@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4A748AD15D7 for ; Mon, 14 Mar 2016 21:07:45 +0000 (UTC) (envelope-from feld@FreeBSD.org) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1DA76D17 for ; Mon, 14 Mar 2016 21:07:44 +0000 (UTC) (envelope-from feld@FreeBSD.org) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 91AC722B13 for ; Mon, 14 Mar 2016 17:07:42 -0400 (EDT) Received: from web3 ([10.202.2.213]) by compute5.internal (MEProxy); Mon, 14 Mar 2016 17:07:42 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=Ax0qXg5Lr28yYsH Tr8SbMU0Ue+o=; b=C9xFer/DMuH4EpsDXWhrK2USgaLJNhsw2Pp5t9nC1n/euPE coGOTNLEUczq7YYQyIDFRDMVvWAF2TzYxBS9/cUcIFFbsmXuWV6xHgKQoRVPPhoN QnVjSkVHrlBHjIJs3kPsMlmlF6c/++aUt6wuWlhmcnvQE2BpMWeamGt2D3g8= Received: by web3.nyi.internal (Postfix, from userid 99) id 664B11065B7; Mon, 14 Mar 2016 17:07:42 -0400 (EDT) Message-Id: <1457989662.568170.549069906.791C2D05@webmail.messagingengine.com> X-Sasl-Enc: t5F8F1k5rtNNrtojVaEPJWyw/tvB1OO2X5PtWtgiKUW8 1457989662 From: Mark Felder To: James Gritton , freebsd-jail@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-da7163a6 In-Reply-To: <0ad738494152d249f3bbe3b722a46bd2@gritton.org> References: <0ad738494152d249f3bbe3b722a46bd2@gritton.org> Subject: Re: SHM objects cannot be isolated in jails, any evolution in future FreeBSD versions? Date: Mon, 14 Mar 2016 16:07:42 -0500 X-BeenThere: freebsd-jail@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Discussion about FreeBSD jail\(8\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2016 21:07:45 -0000 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 -- Mark Felder ports-secteam member feld@FreeBSD.org From owner-freebsd-jail@freebsd.org Mon Mar 14 21:42:30 2016 Return-Path: Delivered-To: freebsd-jail@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 720BBAD0356 for ; Mon, 14 Mar 2016 21:42:30 +0000 (UTC) (envelope-from jamie@freebsd.org) Received: from gritton.org (gritton.org [162.220.209.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.gritton.org", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 435C9D7D; Mon, 14 Mar 2016 21:42:29 +0000 (UTC) (envelope-from jamie@freebsd.org) Received: from gritton.org (gritton.org [162.220.209.3]) by gritton.org (8.15.2/8.15.2) with ESMTPS id u2ELgN4l055350 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 14 Mar 2016 15:42:23 -0600 (MDT) (envelope-from jamie@freebsd.org) Received: (from www@localhost) by gritton.org (8.15.2/8.15.2/Submit) id u2ELgN54055349; Mon, 14 Mar 2016 15:42:23 -0600 (MDT) (envelope-from jamie@freebsd.org) X-Authentication-Warning: gritton.org: www set sender to jamie@freebsd.org using -f To: freebsd-jail@freebsd.org Subject: Re: SHM objects cannot be isolated in jails, any evolution in future FreeBSD versions? X-PHP-Originating-Script: 0:rcube.php MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 14 Mar 2016 15:42:23 -0600 From: James Gritton In-Reply-To: <1457989662.568170.549069906.791C2D05@webmail.messagingengine.com> References: <0ad738494152d249f3bbe3b722a46bd2@gritton.org> <1457989662.568170.549069906.791C2D05@webmail.messagingengine.com> Message-ID: <92e90eb23e9b15bab5066fb0667be9bd@gritton.org> X-Sender: jamie@freebsd.org User-Agent: Roundcube Webmail/1.1.2 X-BeenThere: freebsd-jail@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Discussion about FreeBSD jail\(8\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2016 21:42:30 -0000 On 2016-03-14 15:07, Mark Felder wrote: > 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 Yeah, SYSV IPC has been a need for quite a while (a good deal longer than I've been around). I'm a bit hesitant to put it in right now, since it's apparently part of upcoming vimage work. But since the Posix stuff is (virtually) path-based, it would seem a relatively simple thing to put the jail path to use in keeping those IPC objects separate. - Jamie From owner-freebsd-jail@freebsd.org Tue Mar 15 08:34:57 2016 Return-Path: Delivered-To: freebsd-jail@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7477BAD0B4A for ; Tue, 15 Mar 2016 08:34:57 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3A4C4D7; Tue, 15 Mar 2016 08:34:56 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 7B83D28423; Tue, 15 Mar 2016 09:34:48 +0100 (CET) Received: from illbsd.quip.test (ip-86-49-16-209.net.upcbroadband.cz [86.49.16.209]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id C97D928417; Tue, 15 Mar 2016 09:34:46 +0100 (CET) Message-ID: <56E7C926.3020201@quip.cz> Date: Tue, 15 Mar 2016 09:34:46 +0100 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:35.0) Gecko/20100101 Firefox/35.0 SeaMonkey/2.32 MIME-Version: 1.0 To: Mark Felder , James Gritton , freebsd-jail@freebsd.org Subject: Re: SHM objects cannot be isolated in jails, any evolution in future FreeBSD versions? References: <0ad738494152d249f3bbe3b722a46bd2@gritton.org> <1457989662.568170.549069906.791C2D05@webmail.messagingengine.com> In-Reply-To: <1457989662.568170.549069906.791C2D05@webmail.messagingengine.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-jail@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Discussion about FreeBSD jail\(8\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2016 08:34:57 -0000 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 From owner-freebsd-jail@freebsd.org Tue Mar 15 09:40:24 2016 Return-Path: Delivered-To: freebsd-jail@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 96248AD05B1 for ; Tue, 15 Mar 2016 09:40:24 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5D23D908 for ; Tue, 15 Mar 2016 09:40:23 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id E22C728417; Tue, 15 Mar 2016 10:40:19 +0100 (CET) Received: from illbsd.quip.test (ip-86-49-16-209.net.upcbroadband.cz [86.49.16.209]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 14D8428412; Tue, 15 Mar 2016 10:40:18 +0100 (CET) Message-ID: <56E7D882.8060400@quip.cz> Date: Tue, 15 Mar 2016 10:40:18 +0100 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:35.0) Gecko/20100101 Firefox/35.0 SeaMonkey/2.32 MIME-Version: 1.0 To: "Martin \"eto\" Misuth" , freebsd-jail@freebsd.org Subject: Re: Jail management References: <0f5cae7e-7de3-2617-fcf6-3423d4caf13a@ish.com.au> <56CAE974.4050508@quip.cz> <0eaf61d4-43e6-265a-f773-820244fc8931@ish.com.au> <20160225161413.25f17811@eto-mona.office.smartweb.sk> In-Reply-To: <20160225161413.25f17811@eto-mona.office.smartweb.sk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-jail@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Discussion about FreeBSD jail\(8\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2016 09:40:24 -0000 Martin "eto" Misuth wrote on 02/25/2016 16:14: [...] > - not sure about Miroslav's problems with freebsd-update, but it seems to work > pretty well with -basedir /jail/tree parameter nowadays (there might be > corner cases) Freebsd-update maintains patches for each file in each jail (if you use full jails and not shared basejail) so this is IO / space / time consuming. freebsd-update has some unhandled exceptions which can leave system in an inconsistent state. (unbootable) It ended up with mixed files from 9.x and 10.x on host when updating host. It was about 2 years ago and it may be fixed. I don't know. > - you can have older jail-base run on newest kernel (other way around is not > possible) > - you can kill many files in given jail to get bare minimal running setup > (this seems completely driven by gut, from what I gathered, as some things > might have un-obvious dependencies) > - you can mount many things into jail read-only (this makes them more rigid > and harder to "manage" "live") > - jails can have limits on number of procs living in them and can be > allowed to be nested(!) (jail-in-jail) > - with rctl you can cap resources per jail Beware of RCTL. We are using it a lot but some of them don't work as one can expect from their name and manpage description. Namely memory or swapuse. Limiting of processor seems good. Miroslav Lachman From owner-freebsd-jail@freebsd.org Tue Mar 15 17:19:34 2016 Return-Path: Delivered-To: freebsd-jail@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F2575AD0352 for ; Tue, 15 Mar 2016 17:19:34 +0000 (UTC) (envelope-from mark@exonetric.com) Received: from relay.exonetric.net (relay0.exonetric.net [178.250.72.161]) by mx1.freebsd.org (Postfix) with ESMTP id C5E1614C8; Tue, 15 Mar 2016 17:19:34 +0000 (UTC) (envelope-from mark@exonetric.com) Received: from [10.2.118.214] (host86-187-120-246.range86-187.btcentralplus.com [86.187.120.246]) by relay.exonetric.net (Postfix) with ESMTPSA id B3E6C2B757; Tue, 15 Mar 2016 12:33:49 +0000 (GMT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: SHM objects cannot be isolated in jails, any evolution in future FreeBSD versions? From: Mark Blackman X-Mailer: iPad Mail (13D15) In-Reply-To: <56E7C926.3020201@quip.cz> Date: Tue, 15 Mar 2016 12:33:49 +0000 Cc: Mark Felder , James Gritton , freebsd-jail@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <593EB477-D6AC-463B-A509-86A63455436F@exonetric.com> References: <0ad738494152d249f3bbe3b722a46bd2@gritton.org> <1457989662.568170.549069906.791C2D05@webmail.messagingengine.com> <56E7C926.3020201@quip.cz> To: Miroslav Lachman <000.fbsd@quip.cz> X-BeenThere: freebsd-jail@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Discussion about FreeBSD jail\(8\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2016 17:19:35 -0000 On 15 Mar 2016, at 08:34, Miroslav Lachman <000.fbsd@quip.cz> wrote: >=20 > Mark Felder wrote on 03/14/2016 22:07: >>=20 >>=20 >>> 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: >>>>=20 >>>> - 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. >>>>=20 >>>> 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. >>>>=20 >>>> A reference of such claim: >>>> https://lists.freebsd.org/pipermail/freebsd-ports-bugs/2015-July/312665= .html >>>>=20 >>>> My initial post on FreeBSD forum discussing the issue with more >>>> details: https://forums.freebsd.org/threads/55468/ >>>>=20 >>>> Currently, there does not seem to be any way to prevent this. >>>>=20 >>>> 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. >>>>=20 >>>> 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? >>>=20 >>> 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. >>=20 >> Both this and SYSV IPC jail support[1] are badly needed. >>=20 >> [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D48471 >=20 > 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 thi= ng there was some patch from PJD for SysV IPC too. There were EclipseBSD wit= h resource limits in times of FreeBSD 3.4 and there is FreeVPS for 6.x with v= irtualized IPC... >=20 > So I really hope SysV IPC aware jails will become reality soon. >=20 > Miroslav Lachman Do we have a feeling if this only a funding problem or is it an enthusiasm p= roblem? - Mark From owner-freebsd-jail@freebsd.org Tue Mar 15 18:20:09 2016 Return-Path: Delivered-To: freebsd-jail@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 83929AD215A for ; Tue, 15 Mar 2016 18:20:09 +0000 (UTC) (envelope-from jamie@freebsd.org) Received: from gritton.org (gritton.org [162.220.209.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.gritton.org", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 6A75D144D; Tue, 15 Mar 2016 18:20:09 +0000 (UTC) (envelope-from jamie@freebsd.org) Received: from gritton.org (gritton.org [162.220.209.3]) by gritton.org (8.15.2/8.15.2) with ESMTPS id u2FI8XMB069210 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 15 Mar 2016 12:08:33 -0600 (MDT) (envelope-from jamie@freebsd.org) Received: (from www@localhost) by gritton.org (8.15.2/8.15.2/Submit) id u2FI8Xq0069209; Tue, 15 Mar 2016 12:08:33 -0600 (MDT) (envelope-from jamie@freebsd.org) X-Authentication-Warning: gritton.org: www set sender to jamie@freebsd.org using -f To: freebsd-jail@freebsd.org Subject: Re: SHM objects cannot be isolated in jails, any evolution in future FreeBSD versions? X-PHP-Originating-Script: 0:rcube.php MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 15 Mar 2016 12:08:33 -0600 From: James Gritton In-Reply-To: <593EB477-D6AC-463B-A509-86A63455436F@exonetric.com> References: <0ad738494152d249f3bbe3b722a46bd2@gritton.org> <1457989662.568170.549069906.791C2D05@webmail.messagingengine.com> <56E7C926.3020201@quip.cz> <593EB477-D6AC-463B-A509-86A63455436F@exonetric.com> Message-ID: <8a3aba735138ade07cad0315dcabee69@gritton.org> X-Sender: jamie@freebsd.org User-Agent: Roundcube Webmail/1.1.2 X-BeenThere: freebsd-jail@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Discussion about FreeBSD jail\(8\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2016 18:20:09 -0000 On 2016-03-15 06:33, Mark Blackman wrote: > On 15 Mar 2016, at 08:34, Miroslav Lachman <000.fbsd@quip.cz> wrote: >> 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 > > Do we have a feeling if this only a funding problem or is it an > enthusiasm problem? > > - Mark More of an "I've been hearing about it being around the corner so haven't done anything" problem. I guess that would file under enthusiasm. - Jamie From owner-freebsd-jail@freebsd.org Wed Mar 16 19:15:31 2016 Return-Path: Delivered-To: freebsd-jail@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1DBC5AD3BB6 for ; Wed, 16 Mar 2016 19:15:31 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B27161A3B for ; Wed, 16 Mar 2016 19:15:30 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: by mail-wm0-x232.google.com with SMTP id p65so86714271wmp.0 for ; Wed, 16 Mar 2016 12:15:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=uLenL6l3vZKWtchW1GmrTfOVuGHid0c0Jyks/8pAdNw=; b=CbLSvoj5pt01noF/3YjMkmJgyiPwvFfff8SUBVS18o207W0GXIzqv/nbzsQnVmbJiL D9MUai31fYrzL7L/+b+XO+bqm2Vcemzs8jS+PNU8IZJZUmNhCDqtO8jXDgekuonD2YjH ten9vABoiqBGRN6Q3QaXQmOnDGocP3flPevbkmVJHWRSG77hRQChz1J7glgIjAyclOYO UZf190Agw5mESlMNLwRgNVREIJRztdp25gooTWMnrYJ838mzCt3jn2+lyd1mFemG6H3t Aez5jmBhsXOD3CFILVy1kR11066Jy+QXReBEI0LUDx5SLmAq3sz2iSqcaiuBiDrFxAbS SUcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=uLenL6l3vZKWtchW1GmrTfOVuGHid0c0Jyks/8pAdNw=; b=HsD9vy9f+wYV/MErrVBIkryqksd6pggFR2Eh22SShqIYZqtoDeX1r5hks1hOvIhBrA i0i4v9BmcLNXr4AZWJS2aN96lF3LOoMSCoh1mU8ou6w8o/GQEO3E+LpYGsauCk/ZmHOs Tfc52lJabdkosrEHLROugN7jvEvyjrBM7XLqJce41ZXL1Bsl8cJLCr/x2EYVQPhHhYK7 ix6Fk/xCEH6lrsrgQFqTPE3xENekcxihUgiuRFPhZADRPpkpmfK2IlL3jmeXk4dcF0Xc SQYzORzLjdk6+lFnwkaqt8+JiRX9xB3vZWIUWQBZ78h7MtZ89lGt8s015kcX1sKW9zUl RjCA== X-Gm-Message-State: AD7BkJLvsOSGktkksO3sDGYCPGZEJ/2sthchiFUqQipj4POaozLzvfYwuFPXnuH+I3/PpQ== X-Received: by 10.28.111.12 with SMTP id k12mr6068704wmc.35.1458155729343; Wed, 16 Mar 2016 12:15:29 -0700 (PDT) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by smtp.gmail.com with ESMTPSA id w125sm4804936wmw.18.2016.03.16.12.15.27 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Wed, 16 Mar 2016 12:15:28 -0700 (PDT) Date: Wed, 16 Mar 2016 20:15:25 +0100 From: Mateusz Guzik To: Simon Cc: freebsd-jail@freebsd.org Subject: Re: SHM objects cannot be isolated in jails, any evolution in future FreeBSD versions? Message-ID: <20160316191525.GA4550@dft-labs.eu> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-jail@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Discussion about FreeBSD jail\(8\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2016 19:15:31 -0000 On Sat, Mar 12, 2016 at 12:05:57PM +0100, 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? > Last time I checked there were no inherent problems preventing getting this to work. A half-assed implementation is trivial and boils down semi-automatically changing several places which reference a global pointer to something taken from struct prison and then adding support to jail(8) and ipcs(1). An acceptable implementation would first take several steps to prevent foot-shooting like e.g. make jail_attach'ing processes singlethreaded. The preferred way would first go over the existing codebase and perform necessary cleanups and bugfixes (if any). Either way, there are no apparent actual problems to be solved here, or in other words this looks like a moderate (option 2) to long time effort (option 3). One unclear bit is involvement with VIMAGE. To be more exact it is quite unclear what's the relationship between VNET and VIMAGE. If one had an entire network stack for their jail, they would not mind separate ipcs either. On the other hand having separate ipcs should not require a separate network stack. As such, does not look like this would duplicate too much effort if VIMAGE was to become usable. That said, this is definitely doable. I can have another look, but no promises. -- Mateusz Guzik From owner-freebsd-jail@freebsd.org Thu Mar 17 00:10:50 2016 Return-Path: Delivered-To: freebsd-jail@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E1BD8AD2369 for ; Thu, 17 Mar 2016 00:10:50 +0000 (UTC) (envelope-from dewaynegeraghty@gmail.com) Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 52CB2907 for ; Thu, 17 Mar 2016 00:10:50 +0000 (UTC) (envelope-from dewaynegeraghty@gmail.com) Received: by mail-lf0-x22e.google.com with SMTP id l83so31142771lfd.3 for ; Wed, 16 Mar 2016 17:10:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7C5o6Eqcgda1ksLQA06TC3hO4TBTQwtVln+mgsKlRZg=; b=if0A00HOvVtY/szfz/oAKXxouRnoIdjz5AMXH0O27j7+yzF0VqPU/yx4I4eT25YbUR mq1UGCBzotuFzB0nkApwaQwx3+hJkBCD+8FIuMZ8hPP7KExjVuIQ1BMdDe+6q75yohTr tPyqbXbS6SY6j64QUgypd9Cpd5qSki+1hNJcFD0IL0TQwP7XmXwAd+G/ArbFvzYoEpN8 yI5+HnMaePy8pJFtr1s9Rnv1/gSWDLeoTjLY0Q7spygXNES1aLXSFBAGMm+EUDLKhzMq bkroQJgBgTfBMXIlFduYlhzt8oI9NNoyKW9I0xJeSGeULIgxTy2emwHlG+jQU+fhekwy 6bfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7C5o6Eqcgda1ksLQA06TC3hO4TBTQwtVln+mgsKlRZg=; b=S6q3Y4bjgPKjt94FlHNEckYInYPhXa18DA4VtCLNGcAGHLuBYf9zX2pgX3EF+j1Ccb oYurxcSiiZOtGo7pFWKuDy21G0itR/XxJZw1BW8Fyeej52gFOfrrdKjsZ+R3C4AM4mBD 1kWIMU8xw6HIzLm3o27SwX8iDsF3PRFcQbLKhkVzDYyi0VwToEOJHsfCwxXelnlRDDFt cITx9N2YlnVCyo21QGSUBpDpAxZ7Gigth5jjNmDkOGyMS9uqEgZB1g/RLcUZu4tFs4Hf gMYiUR+FqTKGKxh6DlqPtOfEWCuUi9BUqBWcYZ/qO3wtR3PKupBTy+sKQxpiO4lR8ozi YbhA== X-Gm-Message-State: AD7BkJJH+fXzJXJ3307vagXwGf3enQIv0QyIuCJi63en7aoyu37h3v9YJvGGomayS9nPUZtV92BlxTg4wtzoiw== X-Received: by 10.25.218.1 with SMTP id r1mr1988050lfg.63.1458173448586; Wed, 16 Mar 2016 17:10:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.142.83 with HTTP; Wed, 16 Mar 2016 17:10:18 -0700 (PDT) In-Reply-To: <20160316191525.GA4550@dft-labs.eu> References: <20160316191525.GA4550@dft-labs.eu> From: Dewayne Geraghty Date: Thu, 17 Mar 2016 11:10:18 +1100 Message-ID: Subject: Re: SHM objects cannot be isolated in jails, any evolution in future FreeBSD versions? To: Mateusz Guzik Cc: Simon , freebsd-jail@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: freebsd-jail@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Discussion about FreeBSD jail\(8\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2016 00:10:51 -0000 Mateusz, Anything that you can do to address this, would be greatly appreciated. Thanks for taking the time to have another look. Having a globally accessible namespace is a potential vulnerability where multiple sendmail &/or postgresql clusters are running. Its not unreasonable to have: - a (sendmail) mailhost jail for internal users, and a public MTA (jail) facing the Internet running on the same box; and - and similarly, for small businesses to have a critical postgresql jail for internal services and a public web-connected postgresql services' jail; all on the one physical box. I haven't written a line of C since '91, but happy to test and feedback in timely manner. Kind regards, Dewayne. 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 :) On 17 March 2016 at 06:15, Mateusz Guzik wrote: > On Sat, Mar 12, 2016 at 12:05:57PM +0100, 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? > > > > Last time I checked there were no inherent problems preventing getting > this to work. > > A half-assed implementation is trivial and boils down semi-automatically > changing several places which reference a global pointer to something > taken from struct prison and then adding support to jail(8) and ipcs(1). > > An acceptable implementation would first take several steps to prevent > foot-shooting like e.g. make jail_attach'ing processes singlethreaded. > > The preferred way would first go over the existing codebase and perform > necessary cleanups and bugfixes (if any). > > Either way, there are no apparent actual problems to be solved here, or > in other words this looks like a moderate (option 2) to long time effort > (option 3). > > One unclear bit is involvement with VIMAGE. To be more exact it is quite > unclear what's the relationship between VNET and VIMAGE. If one had an > entire network stack for their jail, they would not mind separate ipcs > either. On the other hand having separate ipcs should not require a > separate network stack. As such, does not look like this would duplicate > too much effort if VIMAGE was to become usable. > > That said, this is definitely doable. I can have another look, but no > promises. > > -- > Mateusz Guzik > _______________________________________________ > freebsd-jail@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-jail > To unsubscribe, send any mail to "freebsd-jail-unsubscribe@freebsd.org" > -- *Disclaimer:* *As implied by email protocols, the information in this message is not confidential. Any intermediary or recipient may inspect, modify (add), copy, forward, reply to, delete, or filter email for any purpose unless said parties are otherwise obligated. Nothing in this message may be legally binding without cryptographic evidence of its integrity and/or confidentiality.* From owner-freebsd-jail@freebsd.org Thu Mar 17 11:54:59 2016 Return-Path: Delivered-To: freebsd-jail@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4F795AD4A16; Thu, 17 Mar 2016 11:54:59 +0000 (UTC) (envelope-from freebsd.lists@whitewinterwolf.com) Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [IPv6:2001:4b98:c:538::197]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1763A10F3; Thu, 17 Mar 2016 11:54:59 +0000 (UTC) (envelope-from freebsd.lists@whitewinterwolf.com) Received: from mfilter30-d.gandi.net (mfilter30-d.gandi.net [217.70.178.161]) by relay5-d.mail.gandi.net (Postfix) with ESMTP id 54EDF41C0B1; Thu, 17 Mar 2016 12:54:48 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter30-d.gandi.net Received: from relay5-d.mail.gandi.net ([IPv6:::ffff:217.70.183.197]) by mfilter30-d.gandi.net (mfilter30-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id ArqtKMl_S8XG; Thu, 17 Mar 2016 12:54:46 +0100 (CET) X-Originating-IP: 10.58.1.150 Received: from webmail.eu.com (webmail10-d.mgt.gandi.net [10.58.1.150]) (Authenticated sender: lists@whitewinterwolf.com) by relay5-d.mail.gandi.net (Postfix) with ESMTPA id 410CD41C08B; Thu, 17 Mar 2016 12:54:45 +0100 (CET) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Thu, 17 Mar 2016 12:54:45 +0100 From: Simon To: Miroslav Lachman <000.fbsd@quip.cz> Cc: Mark Felder , James Gritton , freebsd-jail@freebsd.org, owner-freebsd-jail@freebsd.org Subject: Re: SHM objects cannot be isolated in jails, any evolution in future FreeBSD versions? In-Reply-To: <56E7C926.3020201@quip.cz> References: <0ad738494152d249f3bbe3b722a46bd2@gritton.org> <1457989662.568170.549069906.791C2D05@webmail.messagingengine.com> <56E7C926.3020201@quip.cz> Message-ID: <27abd17bc67680df02ef6d06f31d77be@whitewinterwolf.com> X-Sender: freebsd.lists@whitewinterwolf.com User-Agent: Roundcube Webmail/1.1.2 X-BeenThere: freebsd-jail@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Discussion about FreeBSD jail\(8\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2016 11:54:59 -0000 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.