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