SHM objects cannot be isolated in jails, any evolution in future FreeBSD versions?

[Dewayne Geraghty]

Mateusz,

Anything that you can do to address this, would be greatly appreciated.
Thanks for taking the time to have another look.

Having a globally accessible namespace is a potential vulnerability where
multiple sendmail &/or postgresql clusters are running.  Its not
unreasonable to have:
- a (sendmail) mailhost jail for internal users, and a public MTA (jail)
facing the Internet running on the same box; and
- and similarly, for small businesses to have a critical postgresql jail
for internal services and a public web-connected postgresql services' jail;
all on the one physical box.

I haven't written a line of C since '91, but happy to test and feedback in
timely manner.
Kind regards, Dewayne.
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 :)

On 17 March 2016 at 06:15, Mateusz Guzik <mjguzik at gmail.com> wrote:

> On Sat, Mar 12, 2016 at 12:05:57PM +0100, 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?
> >
>
> Last time I checked there were no inherent problems preventing getting
> this to work.
>
> A half-assed implementation is trivial and boils down semi-automatically
> changing several places which reference a global pointer to something
> taken from struct prison and then adding support to jail(8) and ipcs(1).
>
> An acceptable implementation would first take several steps to prevent
> foot-shooting like e.g. make jail_attach'ing processes singlethreaded.
>
> The preferred way would first go over the existing codebase and perform
> necessary cleanups and bugfixes (if any).
>
> Either way, there are no apparent actual problems to be solved here, or
> in other words this looks like a moderate (option 2) to long time effort
> (option 3).
>
> One unclear bit is involvement with VIMAGE. To be more exact it is quite
> unclear what's the relationship between VNET and VIMAGE. If one had an
> entire network stack for their jail, they would not mind separate ipcs
> either. On the other hand having separate ipcs should not require a
> separate network stack. As such, does not look like this would duplicate
> too much effort if VIMAGE was to become usable.
>
> That said, this is definitely doable. I can have another look, but no
> promises.
>
> --
> Mateusz Guzik <mjguzik gmail.com>
> _______________________________________________
> freebsd-jail at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-jail
> To unsubscribe, send any mail to "freebsd-jail-unsubscribe at freebsd.org"
>



-- 
*Disclaimer:*



*As implied by email protocols, the information in this message is not
confidential. Any intermediary or recipient may inspect, modify (add),
copy, forward, reply to, delete, or filter email for any purpose unless
said parties are otherwise obligated.  Nothing in this message may be
legally binding without cryptographic evidence of its integrity and/or
confidentiality.*