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"
