lkml.org 
[lkml]   [2004]   [Nov]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Further shmctl() SHM_LOCK strangeness
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 ++
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:08    [W:0.054 / U:0.096 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site