From owner-freebsd-jail@freebsd.org Sat Mar 12 11:06:03 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 3AF24ACD251 for ; Sat, 12 Mar 2016 11:06:03 +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 04FC0A6 for ; Sat, 12 Mar 2016 11:06:02 +0000 (UTC) (envelope-from freebsd.lists@whitewinterwolf.com) Received: from mfilter45-d.gandi.net (mfilter45-d.gandi.net [217.70.178.176]) by relay5-d.mail.gandi.net (Postfix) with ESMTP id B06B441C08B for ; Sat, 12 Mar 2016 12:05:59 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter45-d.gandi.net Received: from relay5-d.mail.gandi.net ([IPv6:::ffff:217.70.183.197]) by mfilter45-d.gandi.net (mfilter45-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id oKKQvQ27q4-A for ; Sat, 12 Mar 2016 12:05:58 +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 1162E41C051 for ; Sat, 12 Mar 2016 12:05:57 +0100 (CET) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Sat, 12 Mar 2016 12:05:57 +0100 From: Simon To: freebsd-jail@freebsd.org Subject: SHM objects cannot be isolated in jails, any evolution in future FreeBSD versions? Message-ID: 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: Sat, 12 Mar 2016 11:06:03 -0000 Hello all, 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? Thank you by advance for your answers! Simon. From owner-freebsd-jail@freebsd.org Sat Mar 12 16:50:01 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 825E3ACE4F2 for ; Sat, 12 Mar 2016 16:50:01 +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 64464CD1 for ; Sat, 12 Mar 2016 16:50:01 +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 u2CGgYXP018541 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 12 Mar 2016 09:42:34 -0700 (MST) (envelope-from jamie@freebsd.org) Received: (from www@localhost) by gritton.org (8.15.2/8.15.2/Submit) id u2CGgXaA018540; Sat, 12 Mar 2016 09:42:33 -0700 (MST) (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: Sat, 12 Mar 2016 09:42:33 -0700 From: James Gritton In-Reply-To: References: Message-ID: <0ad738494152d249f3bbe3b722a46bd2@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: Sat, 12 Mar 2016 16:50:01 -0000 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. - Jamie