Date: Sun, 7 Jun 2015 10:37:34 +0200 From: Mateusz Guzik <mjguzik@gmail.com> To: kikuchan <kikuchan@uranus.dti.ne.jp> Cc: freebsd-jail@freebsd.org, freebsd-stable@freebsd.org Subject: Re: [patch] separate SysV IPC namespace for jail Message-ID: <20150607083734.GB9182@dft-labs.eu> In-Reply-To: <CAG40kxFaD%2BTS3Asb7ZiRW67XLtMOe6ChDEVgkSnt1Ji3013j4w@mail.gmail.com> References: <CAG40kxFFnfvbLbqVprPC0oZ%2BnbKDYGxdvgd-vxWXFfN%2B3NQ0_A@mail.gmail.com> <20150605235348.GA9965@dft-labs.eu> <CAG40kxEaOAmcOCwb7p6NF6sgox-KysKh2RJgG7og1fi0WL0-Sg@mail.gmail.com> <20150607013929.GA9182@dft-labs.eu> <CAG40kxFaD%2BTS3Asb7ZiRW67XLtMOe6ChDEVgkSnt1Ji3013j4w@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Jun 07, 2015 at 04:43:16PM +0900, kikuchan wrote: > Hi Mateusz, > > Thanks for your reply! > > First of all, I intend to *jail* SysV IPC user completely. > (unless user really want to interact with each other between jails) > > I think SysV IPC is simple but obsolete, so you can design whatever > you want for jail system. > Also, I want keep everything simple. > > My design (to be sure): > - Each entry of the list (shown in ipcs) belongs to a jail. > - Any operation to SHM/SEM/MSG attempted from another jail, will just > fail with EACCES. > But why? See below. > > > "Address space can be shared between multiple PROCESSES, what happens if > > such a pair ends up in different jails? Preferably such a scenario would > > be prohibited to avoid future accidents." > > > > However, sysvipc namespace sharing is an ok feature esp. with > > multi-level jails. In the simplest scenario upon jail creation you > > decide whether it gets its own namespace or inherits it. > > > > > > What about existing sysvshm mappings when jailing? > > > > > > Real (not jailed) environment is treated as a jail with jid=0 in kernel. > > > If you create sysvshm memory segment before entering a jail, the > > > segment simply owned by jid=0. > > > > > > > The point is you get a process with sysvshm segments from 2 different > > jails. Looks like solid trouble protential. > > Ok, I think I've got what you'd concerned. > > In my design, setting up such processes would be difficult. > This wouldn't be happend normally, because shared memory segments > should be obtained BEFORE entering a jail; > > 1. Create a segment on jid=0 with shmget() > 2. shmat() to attach (get void *ptr) > 3. fork() > 4. A child process entering to jid=1 with jail_attach() > 5. The child process and the parent process can share the address > space (via *ptr). > 6. If the child process do shmat() on the same ID again, it simply > failed with EACCES. > > It means, there is NO way to obtain a segment created in other jail > AFTER jailed (even if you're root or obtaining the segment created on > jid=0). This is sharing a page, not an address space (see below). This poses serious problems if actual separate namespaces are implemented, otherwise it only leaves a potential for bugs for no real gain. > > As a minimum this is singlethreading > > when jailing, prevention of jailing processes with shared virtual address > > spaces and ones with existing sysvshm mappings. All this is to reduce > > amount of bugs one would have to deal with. > > Virtual memory allocation and related stuff are protected and done by > kernel already, because it's an IPC (Inter Process Communication). > Moreover, you cannot change an owner of the IPC entry after creation, > so we don't need an additional protection in kernel. > Here is an example race: on fork memory mappings are copied first, sysvshm data is updated /later/. What happens if one of the calling threads enters a jail while some other thread is forking? This may be buggy as it is already, but that's roughly the scheme. It looks like we have some weird miscommunication here, so let me restate. I do see great benefit in having jail-aware ipcs. I do not believe the way to achieve it is to add jail-aware permission checks. Support in question should provide support for separate namespaces. The are several upsides, including lack of conflict between jails and plugged infoleaks. In general I don't understand why you insist on your approach, I does not have any advantage over separate namespaces that I could see. -- Mateusz Guzik <mjguzik gmail.com>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150607083734.GB9182>