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.