SHM objects cannot be isolated in jails, any evolution in future FreeBSD versions?
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. ___ freebsd-jail@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-jail To unsubscribe, send any mail to "freebsd-jail-unsubscr...@freebsd.org"
Re: SHM objects cannot be isolated in jails, any evolution in future FreeBSD versions?
On 2016-03-12 04:05, Simon wrote: 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? There are no concrete plans I'm aware of, but it's definitely a thing that should be done. How about filing a bug report for it? You've already got a good write-up of the situation. - Jamie ___ freebsd-jail@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-jail To unsubscribe, send any mail to "freebsd-jail-unsubscr...@freebsd.org"
