SHM objects cannot be isolated in jails, any evolution in future FreeBSD versions?

[Mateusz Guzik]

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 <mjguzik gmail.com>