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
haveaccess to System V IPC primitives. In the current jail imple- mentation, System V primitives share a
singlenamespace across the host and jail environments, meaning that processes within a jail would be
ableto communicate with (and potentially interfere with) processes outside of the jail, and in other jails.
Assuch, this functionality is disabled by default, but can be enabled by setting this MIB entry to
1.
