Re: Further shmctl() SHM_LOCK strangeness

["Michael Kerrisk" <mtk-lkml@gmx.net>]

Rik,

> On Thu, 25 Nov 2004, Michael Kerrisk wrote:
> 
> > As noted by Hugh, the problem also applies for
> > SHM_UNLOCK: anyone can unlock any System V shared
> > memory segment.  If our reason for locking memory
> > was security (no swapping), then this does allow
> > for exploits.
> 
> Good point.  I guess that for SHM_UNLOCK operations
> we need to check for either:
> 
> 1) current->user is the same user who SHM_LOCKed the
>     segment in question

I don't think this is sufficient -- there must
be protection against arbitrary SHM_LOCKs.

> or
> 
> 2) the process has the correct capabilities set

How about the following:

For *both* SHM_LOCK and SHM_UNLOCK, the process should either 
be the owner or the creator of the object or have the 
CAP_IPC_LOCK capability.

Note the following:

1. SHM_LOCK should be covered so that a process with a high
   RLIMIT_MEMLOCK is allowed to lock arbitrary segments 
   that it  doesn't own.

2. A framework like the above is consistent with the 
   semantics of the existing shmctl() IPC_SET and IPC_RMID
   operations (see the shmctl(2) man page).

Cheers,

Michael

-- 
Geschenkt: 3 Monate GMX ProMail + 3 Top-Spielfilme auf DVD
++ Jetzt kostenlos testen http://www.gmx.net/de/go/mail ++