[Bug 208082] SHM objects cannot be isolated in jails

bugzilla-noreply at freebsd.org bugzilla-noreply at freebsd.org
Thu Mar 17 11:32:22 UTC 2016


            Bug ID: 208082
           Summary: SHM objects cannot be isolated in jails
           Product: Base System
           Version: 10.1-RELEASE
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: kern
          Assignee: freebsd-bugs at FreeBSD.org
          Reporter: freebsd.bugs at whitewinterwolf.com

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 anymore
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.

This issue might be related to bug #48471 "private IPC for every jail",
however it doesn't seem as a duplicate to me since IPCs still benefit
from a minimum amount of control using some `sysctl' values, while
there is currently no way to limit in any way shm_open() based memory
objects sharing.

Moreover, the fact that SHM objects are path-based may offer different,
possibly easier to implement solutions in jail context (I have seen
several claims that SHM objects created in jails were indeed handled
differently than ones created in host, but I've found evidence of this).

This issue has been discussed:

- On the FreeBSD forum (with some sample code allowing to establish a
communication channel between two jails):

- In the FreeBSD jail mailing list:

You are receiving this mail because:
You are the assignee for the bug.

More information about the freebsd-bugs mailing list