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
Created attachment 168515 [details] Tie shm/ksem/mqueue namespace to jail root paths Here's a patch that keeps jails separate. Since the SHM objects use filename-ish names, I've use the jails' paths to differentiate them. This means that two different jails with the same root path will still see the same objects, and that the base system can see all jailed objects (which will be found in a "pathname" under the jail's path). Unlike the full inter-jail sharing that currently exists, I consider this sharing a feature. ksem objects (as opposed to the userspace-based shm objects) use essentially the same non-filename pathname code, and have gotten essentially the same patch. mqueue objects have a differently coded non-filename pathname, that is also shared between jails. Unlike shm and ksem, these "filenames" are non-hierarchical, and so I can't handle them the same way. I've still kept them based on the jail root, since it's still the spirit of something that looks kind of like a filename, but there's no way for the system to see jail-based mqueue objects. Unfortunately, using the same code as shm and ksem would be a lot of work, since there's this (incomplete and buggy) mqueuefs that I don't want to mess with.
Hello Jamie, Just to let you know, I've tested the patch and it correctly solves the issue I was encountering. I agree with you that the possibility from the host system to access jails' objects is a feature to keep, as long as the host may not mistake them as its own which is not the case here so that's fine. Thank you for your work for this!
(In reply to Jamie Gritton from comment #1) Jamie, Thank-you for the patch. Will you be adding this to head as it does solve the largest part of the shm issue; mqueue notwithstanding?
Yes, it's time for me to commit. There's some feedback I've been waiting on, but it can always come later.
A commit references this bug: Author: jamie Date: Wed Apr 13 20:14:13 UTC 2016 New revision: 297935 URL: https://svnweb.freebsd.org/changeset/base/297935 Log: Separate POSIX sem/shm objects in jails, by prepending the jail's path name to the object's "path". While the objects don't have real path names, it's a filesystem-like namespace, which allows jails to be kept to their own space, but still allows the system / jail parent to access a jail's IPC. PR: 208082 Changes: head/sys/kern/uipc_sem.c head/sys/kern/uipc_shm.c
A commit references this bug: Author: jamie Date: Wed Apr 13 20:15:49 UTC 2016 New revision: 297936 URL: https://svnweb.freebsd.org/changeset/base/297936 Log: Separate POSIX mqueue objects in jails; actually, separate them by the jail's root, so jails that don't have their own filesystem directory also won't have their own mqueue namespace. PR: 208082 Changes: head/sys/kern/uipc_mqueue.c
A commit references this bug: Author: jamie Date: Mon Nov 13 23:21:18 UTC 2017 New revision: 325783 URL: https://svnweb.freebsd.org/changeset/base/325783 Log: MFC r297935: Separate POSIX sem/shm objects in jails, by prepending the jail's path name to the object's "path". While the objects don't have real path names, it's a filesystem-like namespace, which allows jails to be kept to their own space, but still allows the system / jail parent to access a jail's IPC. MFC r297936: Separate POSIX mqueue objects in jails; actually, separate them by the jail's root, so jails that don't have their own filesystem directory also won't have their own mqueue namespace. MFC r297976: Clean up some style(9) violations. MFC r298567: Use the new PR_METHOD_REMOVE to clean up jail handling in POSIX message queues. PR: 208082 Submitted by: delphij Changes: _U stable/10/ stable/10/sys/kern/uipc_mqueue.c stable/10/sys/kern/uipc_sem.c stable/10/sys/kern/uipc_shm.c