https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=208082
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@FreeBSD.org
Reporter: freebsd.b...@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):
https://forums.freebsd.org/threads/55468/
- In the FreeBSD jail mailing list:
https://lists.freebsd.org/pipermail/freebsd-jail/2016-March/003004.html
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
