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

Simon freebsd.lists at whitewinterwolf.com
Sat Mar 12 11:06:03 UTC 2016


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.



More information about the freebsd-jail mailing list