From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 26 22:05:47 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E740816A4CE for ; Fri, 26 Nov 2004 22:05:47 +0000 (GMT) Received: from mailhost.stack.nl (vaak.stack.nl [131.155.140.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id A974C43D2D for ; Fri, 26 Nov 2004 22:05:47 +0000 (GMT) (envelope-from jilles@stack.nl) Received: from turtle.stack.nl (turtle.stack.nl [IPv6:2001:610:1108:5010::132]) by mailhost.stack.nl (Postfix) with ESMTP id E4F111F098 for ; Fri, 26 Nov 2004 23:05:46 +0100 (CET) Received: by turtle.stack.nl (Postfix, from userid 1677) id D3E701CDDD; Fri, 26 Nov 2004 23:05:46 +0100 (CET) Date: Fri, 26 Nov 2004 23:05:46 +0100 From: Jilles Tjoelker Cc: freebsd-hackers@freebsd.org Message-ID: <20041126220546.GF47714@stack.nl> References: <20041126193800.GB11747@metro.cx> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041126193800.GB11747@metro.cx> X-Operating-System: FreeBSD 5.3-RELEASE-p1 i386 User-Agent: Mutt/1.5.6i Subject: Re: Jail + sysv shmem X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Nov 2004 22:05:48 -0000 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