From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 27 20:43:12 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 A0B8316A4CE for ; Sat, 27 Nov 2004 20:43:12 +0000 (GMT) Received: from sendmail.metro.cx (sonolo.xs4all.nl [80.126.206.91]) by mx1.FreeBSD.org (Postfix) with ESMTP id 346E643D4C for ; Sat, 27 Nov 2004 20:43:11 +0000 (GMT) (envelope-from SRS0=oAAs2a=ON=dave.dh.sono=gmc@metro.cx) Received: from dave.dh.sono (dave.dh.sono [10.1.2.5]) by sendmail.metro.cx (8.13.1/8.13.1) with ESMTP id iARKhAcb028438; Sat, 27 Nov 2004 20:43:10 GMT Received-SPF: none (sendmail.metro.cx: 10.1.2.5 is neither permitted nor denied by domain of dave.dh.sono>) client-ip=10.1.2.5; envelope-from=; helo=dave.dh.sono; Received: from dave.dh.sono (localhost [127.0.0.1]) by dave.dh.sono (8.12.9-20030917/8.12.9) with ESMTP id iARKh9dS005359 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 27 Nov 2004 21:43:09 +0100 Received: (from gmc@localhost) by dave.dh.sono (8.12.9-20030917/8.12.9/Submit) id iARKh95A005358; Sat, 27 Nov 2004 21:43:09 +0100 Date: Sat, 27 Nov 2004 21:43:09 +0100 From: Koen Martens , cx@metro.cx To: Jilles Tjoelker Message-ID: <20041127204309.GB19733@metro.cx> References: <20041126193800.GB11747@metro.cx> <20041126215843.GE47714@stack.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041126215843.GE47714@stack.nl> User-Agent: Mutt/1.4.1i X-PGP-Key: http://www.metro.cx/pubkey-gmc.asc X-Helo-Milter-Helo: dave.dh.sono X-Helo-Milter-Hostname: dave.dh.sono X-Helo-Milter-Ip: 10.1.2.5 cc: Koen Martens cc: freebsd-hackers@freebsd.org 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: Sat, 27 Nov 2004 20:43:12 -0000 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/