On 2016-03-17 05:54, Simon wrote:
Le 2016-03-15 09:34, Miroslav Lachman a écrit :
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
Hi everyone,
Odd thing, I've seen that the very first exchanges which opened this
mailing list back in 2007 precisely discussed IPC isolation in Jail
and some work already done in the Jail2 project part of the now
abandoned FreeVPS project. At that time IPC virtualization was
qualified as an easy job:
As say about SYSV IPC stuff you say about only virtualization? or
also about limits? "virtualization" is easy, but for limits - need
more
work
(https://lists.freebsd.org/pipermail/freebsd-jail/2007-May/000004.html)
We have now come full circle :).
As per the SHM objects issue, I've now filled a new bug #208082:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=208082
I explain in the bug description why it may be different than the
already existing bug #48471 covering SysV IPC.
Le 2016-03-17 01:10, Dewayne Geraghty a écrit :
PS We don't want/need the complexity (or performance hit) associated
with v* additions when a well thought out (simple) jail does the task
very nicely :)
I agree, the main advantage of jails and other lightweight containers
is precisely their lightness.
Regards,
Simon.
I've put a diff on the bug report (Bug 208082), for the shm objects, and
also for ksem and mqueue which have the same problems. Any review is
welcome :-).
SYSV IPC is a separate issue. I'm following up with bz about my memory
of hearing there's something vimage-related there, and if there isn't I
can jump into that one as well (I actually have some work already done
with it, so it just needs a little more).
- 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"
