[HACKERS] semaphore usage "port based"?

[Kris Kennaway]

On Mon, Apr 03, 2006 at 03:42:51PM -0400, Stephen Frost wrote:
> * Tom Lane (tgl at sss.pgh.pa.us) wrote:
> > That's a fair question, but in the context of the code I believe we are
> > behaving reasonably.  The reason this code exists is to provide some
> > insurance against leaking semaphores when a postmaster process is
> > terminated unexpectedly (ye olde often-recommended-against "kill -9
> > postmaster", for instance).  If the PID returned by GETPID is
> 
> Could this be handled sensibly by using SEM_UNDO?  Just a thought.
> 
> > 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 was stated already upthread, but sysv IPC is disabled by default
in jails for precisely this reason.  So yes, when you turn it on it's
a potential security problem if your jails are supposed to be
compartmentalized.

Kris
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20060403/3b1a4b94/attachment.pgp