Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 14 Mar 2016 15:42:23 -0600
From:      James Gritton <jamie@freebsd.org>
To:        freebsd-jail@freebsd.org
Subject:   Re: SHM objects cannot be isolated in jails, any evolution in future   FreeBSD versions?
Message-ID:  <92e90eb23e9b15bab5066fb0667be9bd@gritton.org>
In-Reply-To: <1457989662.568170.549069906.791C2D05@webmail.messagingengine.com>
References:  <c1e2fc0269e9de3a653d6e47da26b026@whitewinterwolf.com> <0ad738494152d249f3bbe3b722a46bd2@gritton.org> <1457989662.568170.549069906.791C2D05@webmail.messagingengine.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?92e90eb23e9b15bab5066fb0667be9bd>