From owner-freebsd-jail@FreeBSD.ORG Mon Jun 8 17:17:09 2015 Return-Path: Delivered-To: freebsd-jail@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4151F8B5; Mon, 8 Jun 2015 17:17:09 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DAE4619BE; Mon, 8 Jun 2015 17:17:08 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: by wgez8 with SMTP id z8so108624513wge.0; Mon, 08 Jun 2015 10:17:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=cM+WLLwDU4aST7D1BjBpR631KfxU8jZom4piDveOD5Y=; b=SZd+Y0jzH12/O7REeN+r+vufC6lSVoBtirwx9BAOXVqe8gLjPd0KejJpOuBUBxYhwl 61fRgQLtPP1LkrjrJCSw1EElZfqjVDeYvVU5HCKaKWR5DnAu407phqejBWn6gUVJsTXG J0B+Mtr6cSI81RrWD/PYU5lsDocv61fp6P1wtZuoI7PgwFjMEoae/ZSlo0Y1T6bpS8Rl EGhPhMTix2cXxFMo8Aj8WCWccozXeb2unGJIaaF1gKVwSVxqWq/9Yu5P1LG3R4mkwwWB eth/a324Q8Elw1V6VmtGqu3eVK2XHa/eAJj5B6/laB60zN55IsOZRO6KYI29n8h/nXqg bVXg== X-Received: by 10.180.77.102 with SMTP id r6mr82167wiw.87.1433783827306; Mon, 08 Jun 2015 10:17:07 -0700 (PDT) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPSA id gw7sm2032939wib.15.2015.06.08.10.17.05 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Mon, 08 Jun 2015 10:17:05 -0700 (PDT) Date: Mon, 8 Jun 2015 19:17:03 +0200 From: Mateusz Guzik To: kikuchan Cc: freebsd-jail@freebsd.org, freebsd-stable@freebsd.org Subject: Re: [patch] separate SysV IPC namespace for jail Message-ID: <20150608171702.GA15516@dft-labs.eu> References: <20150605235348.GA9965@dft-labs.eu> <20150607013929.GA9182@dft-labs.eu> <20150607083734.GB9182@dft-labs.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-jail@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Discussion about FreeBSD jail\(8\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2015 17:17:09 -0000 On Mon, Jun 08, 2015 at 01:42:21AM +0900, kikuchan wrote: > From my curiosity, is my patch a technically bad? > Is there race condition in it? Or, enabling key_t separation for jail > could trigger race condition, perhaps? > I only briefly looked at the patch. The fact that you perform outside of ipcperm looks suspicious but may be harmless, so at best it's a bad style. If you need ipc mechanism-specifc functions, make them call ipcperm instead. The jail check is too simplistic. Jails higher in the hierarchy should be able to access whatever lower jails produced. > > > 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. > > Sorry but I might misunderstand what your "separate namespaces" means. > What namespace are you going to separate? key_t, shmid, kernel > structure of shm, or others? > What features do your "jail-aware ipcs" provide? > Well, as I said in my first mail the idea is to make ipc code look at structures assigned to given jail, so that we can have multiple jails with only their own objects. No "well, this id is used by other jail", unless the namespace is explicitly shared. I did have a patch with a meh implementation doing this, but I lost it along the way. It is easy to implement it for "private purposes" (i.e. disregarding possible attacks with jailing processes). The real work is making the whole business safe. For instance back then I could not find any reliable mechanism to tell me whether given process has a shared address space. There is only a vm_refcnt counter in vmspace which is modified on various occasions, thus is not suitable. Adding a separate counter sucks and adding a "once set, never cleared flag" sucks as well. Maybe there is a good method. -- Mateusz Guzik