From owner-freebsd-stable@FreeBSD.ORG Mon Apr 3 22:37:43 2006 Return-Path: X-Original-To: freebsd-stable@FreeBSD.org Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C871C16A420 for ; Mon, 3 Apr 2006 22:37:43 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id C928B43D70 for ; Mon, 3 Apr 2006 22:37:34 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 00E7C46C45; Mon, 3 Apr 2006 18:37:34 -0400 (EDT) Date: Mon, 3 Apr 2006 23:37:33 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Stephen Frost In-Reply-To: <20060403194251.GF4474@ns.snowman.net> Message-ID: <20060403233540.D76562@fledge.watson.org> References: <26796.1144028094@sss.pgh.pa.us> <20060402225204.U947@ganymede.hub.org> <26985.1144029657@sss.pgh.pa.us> <20060402231232.C947@ganymede.hub.org> <27148.1144030940@sss.pgh.pa.us> <20060402232832.M947@ganymede.hub.org> <20060402234459.Y947@ganymede.hub.org> <27417.1144033691@sss.pgh.pa.us> <20060403164139.D36756@fledge.watson.org> <14654.1144082224@sss.pgh.pa.us> <20060403194251.GF4474@ns.snowman.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Tom Lane , "Marc G. Fournier" , pgsql-hackers@postgresql.org, freebsd-stable@FreeBSD.org, Kris Kennaway Subject: Re: [HACKERS] semaphore usage "port based"? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2006 22:37:43 -0000 On Mon, 3 Apr 2006, Stephen Frost wrote: >> So I think the code is pretty bulletproof as long as it's in a system that >> is behaving per SysV spec. The problem in the current FBSD situation is >> that the jail mechanism is exposing semaphore sets across jails, but not >> exposing the existence of the owning processes. That behavior is >> inconsistent: if process A can affect the state of a sema set that process >> B can see, it's surely unreasonable to pretend that A doesn't exist. > > This is certainly a problem with FBSD jails... Not only the inconsistancy, > but what happens if someone manages to get access to the appropriate uid > under one jail and starts sniffing or messing with the semaphores or shared > memory segments from other jails? If that's possible then that's a rather > glaring security problem... This is why it's disabled by default, and the jail documentation specifically advises of this possibility. Excerpt below. Robert N M Watson security.jail.sysvipc_allowed This MIB entry determines whether or not processes within a jail have access to System V IPC primitives. In the current jail imple- mentation, System V primitives share a single namespace across the host and jail environments, meaning that processes within a jail would be able to communicate with (and potentially interfere with) processes outside of the jail, and in other jails. As such, this functionality is disabled by default, but can be enabled by setting this MIB entry to 1.