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