Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 3 Apr 2006 20:41:06 -0300 (ADT)
From:      "Marc G. Fournier" <scrappy@hub.org>
To:        Robert Watson <rwatson@FreeBSD.org>
Cc:        Daniel Eischen <deischen@freebsd.org>, Peter Jeremy <peterjeremy@optushome.com.au>, freebsd-stable@freebsd.org
Subject:   Re: [HACKERS] semaphore usage "port based"?
Message-ID:  <20060403204031.V947@ganymede.hub.org>
In-Reply-To: <20060403234918.X76562@fledge.watson.org>
References:  <Pine.GSO.4.43.0604031454030.22397-100000@sea.ntplx.net> <20060403163039.O947@ganymede.hub.org> <20060403234918.X76562@fledge.watson.org>

next in thread | previous in thread | raw e-mail | index | archive | help
yOn Mon, 3 Apr 2006, Robert Watson wrote:

>
> On Mon, 3 Apr 2006, Marc G. Fournier wrote:
>
>> This falls under "well,we broke kill() so that it now reports a PID is not 
>> in use even though it is, so its has to be the application that fixes it" 
>> ... and you *still* haven't shown *why* kill() reporting a PID is in use, 
>> even if its not in the current jail, is such a security threat ...
>
> It is an issue of completeness and consistency.  We implement a single set of 
> access control checks between processes, and try to avoid exceptions to them. 
> This is one of my largest architectural gripes about access control in 4.x, 
> actually: everywhere you look, the same "check" is implemented differently. 
> Sometimes signal checks are done way, other times, other ways.  Likewise, 
> debugging, monitoring, etc.  In 5.x forward, we use a centralized set of 
> access control checks in order to provide consistent, reliable, and easy to 
> analyze policy.  The more exceptions we introduced, the further we get from 
> that goal.

Agreed, in principle ... its just locking down something without a way 
around it is ... painful :(

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org           Yahoo!: yscrappy              ICQ: 7615664



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