Jail + sysv shmem

Jilles Tjoelker jilles at stack.nl
Fri Nov 26 14:05:48 PST 2004

On Fri, Nov 26, 2004 at 08:38:00PM +0100, Koen Martens wrote:
> For a while i've been wanting shared memory to be usable withing jails,
> but with cross-jail protection. Ie. shared memory is restricted to a
> jail. 

> Recently I've been digging a bit in the freebsd kernel source code
> (which is new to me, been doing quite some linux kernel hacking though).
> It looks like this is actually not _that_ difficult to implement. 

> So, did anyone try this yet? Any pointers?

> I think it can be done by putting the jail id in struct ipc_perm (in
> sys/ipc.h), and then basically editing sysv_{msg,sem,shm}.c to extend
> these checks that are all over there:

>         if (!jail_sysvipc_allowed && jailed(td->td_ucred))
>                 return (ENOSYS);

> Does that sound ok?

You will have trouble if two jails want to use the same IPC key (key_t,
usually a long). This can also happen in rare cases when running
multiple programs (unjailed) that all try to use separate SysV IPC.

In the jail case, this can be abused by attackers by (easily) guessing
the key that an application in another jail will use and using it in
their own jail. The attacker will have to do this before the application
is started, or at almost any time if the application does not run all
the time.

Additionally, certain methods to generate IPC keys may give the same
result in several jails. A common method to generate them is ftok(3).
This uses the lower 8 bits of the st_dev and the lower 16 bits of the
inode number. Therefore, you will get in trouble with hundreds of
similar jails with their own mount.

To avoid these problems, every jail and the outside system would need
their own IPC key space. This is harder to implement and makes access
from the outside system to jailed IPC impossible. Alas, that's how
AT&T's engineers designed SysV IPC decades ago.

Jilles Tjoelker

More information about the freebsd-hackers mailing list