Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 27 Nov 2004 21:43:09 +0100
From:      Koen Martens <fbsd@metro.cx>, cx@metro.cx
To:        Jilles Tjoelker <jilles@stack.nl>
Cc:        freebsd-hackers@freebsd.org
Subject:   Re: Jail + sysv shmem
Message-ID:  <20041127204309.GB19733@metro.cx>
In-Reply-To: <20041126215843.GE47714@stack.nl>
References:  <20041126193800.GB11747@metro.cx> <20041126215843.GE47714@stack.nl>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Nov 26, 2004 at 10:58:43PM +0100, Jilles Tjoelker wrote:
> 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.

Hmm.. Yes..

> 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.

But, when access to the shared resource is denied on the basis of the
jail identifier, at least cross-jail attacks are not allowed anymore.

> 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.

Quite right, this is actually a documented bug of the ftok method. And
having multiple jails makes this a problem. However, when a IPC segment
identifier is always a tuple of jail-id + user key, no clashes should
exist, only within the same jail (and this is unavoidable).

> 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.

Why would one want access from the outside system to the jailed system?
Is this something that is used frequently? Me personally, i want to keep
everything as seperated as possible. Obviously, the host system can
always access the jail file systems, but I do want to prevent the host
system to have IPC xx to the jails. 

My main motivation btw is to be able to run postgres in a jail, which
can only be done by enabling shared mem inside jails, which is not
really an option i think. Alternatively, one can run the postgres server
in the host system, but that is not a good solution either.

I'll just start hacking soon, and see where it leads me :)

Koen

-- 
K.F.J. Martens, Sonologic, http://www.sonologic.nl/
Networking, embedded systems, unix expertise, artificial intelligence.
Public PGP key: http://www.metro.cx/pubkey-gmc.asc
Wondering about the funny attachment your mail program
can't read? Visit http://www.openpgp.org/



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20041127204309.GB19733>