[HACKERS] semaphore usage "port based"?

[Robert Watson]

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.