Re: SHM objects cannot be isolated in jails, any evolution in future FreeBSD versions?
Mark Felder wrote on 03/14/2016 22:07: On Sat, Mar 12, 2016, at 11:42, James Gritton wrote: 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. Both this and SYSV IPC jail support[1] are badly needed. [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=48471 Yes, it is very sad that original patch was not commited, nor commented or improved by core developers for long 13 years. I am not 100% sure but I thing there was some patch from PJD for SysV IPC too. There were EclipseBSD with resource limits in times of FreeBSD 3.4 and there is FreeVPS for 6.x with virtualized IPC... So I really hope SysV IPC aware jails will become reality soon. Miroslav Lachman ___ 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: Jail management
Martin "eto" Misuth wrote on 02/25/2016 16:14: [...] - not sure about Miroslav's problems with freebsd-update, but it seems to work pretty well with -basedir /jail/tree parameter nowadays (there might be corner cases) Freebsd-update maintains patches for each file in each jail (if you use full jails and not shared basejail) so this is IO / space / time consuming. freebsd-update has some unhandled exceptions which can leave system in an inconsistent state. (unbootable) It ended up with mixed files from 9.x and 10.x on host when updating host. It was about 2 years ago and it may be fixed. I don't know. - you can have older jail-base run on newest kernel (other way around is not possible) - you can kill many files in given jail to get bare minimal running setup (this seems completely driven by gut, from what I gathered, as some things might have un-obvious dependencies) - you can mount many things into jail read-only (this makes them more rigid and harder to "manage" "live") - jails can have limits on number of procs living in them and can be allowed to be nested(!) (jail-in-jail) - with rctl you can cap resources per jail Beware of RCTL. We are using it a lot but some of them don't work as one can expect from their name and manpage description. Namely memory or swapuse. Limiting of processor seems good. Miroslav Lachman ___ 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 15 Mar 2016, at 08:34, Miroslav Lachman <000.f...@quip.cz> wrote: > > Mark Felder wrote on 03/14/2016 22:07: >> >> >>> On Sat, Mar 12, 2016, at 11:42, James Gritton wrote: 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. >> >> Both this and SYSV IPC jail support[1] are badly needed. >> >> [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=48471 > > Yes, it is very sad that original patch was not commited, nor commented or > improved by core developers for long 13 years. I am not 100% sure but I thing > there was some patch from PJD for SysV IPC too. There were EclipseBSD with > resource limits in times of FreeBSD 3.4 and there is FreeVPS for 6.x with > virtualized IPC... > > So I really hope SysV IPC aware jails will become reality soon. > > Miroslav Lachman Do we have a feeling if this only a funding problem or is it an enthusiasm problem? - Mark ___ 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-15 06:33, Mark Blackman wrote: On 15 Mar 2016, at 08:34, Miroslav Lachman <000.f...@quip.cz> wrote: Mark Felder wrote on 03/14/2016 22:07: On Sat, Mar 12, 2016, at 11:42, James Gritton wrote: 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. Both this and SYSV IPC jail support[1] are badly needed. [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=48471 Yes, it is very sad that original patch was not commited, nor commented or improved by core developers for long 13 years. I am not 100% sure but I thing there was some patch from PJD for SysV IPC too. There were EclipseBSD with resource limits in times of FreeBSD 3.4 and there is FreeVPS for 6.x with virtualized IPC... So I really hope SysV IPC aware jails will become reality soon. Miroslav Lachman Do we have a feeling if this only a funding problem or is it an enthusiasm problem? - Mark More of an "I've been hearing about it being around the corner so haven't done anything" problem. I guess that would file under enthusiasm. - 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"
