Re: semaphore usage "port based"?

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.