Messages in this thread | | | Date | Thu, 25 Nov 2004 13:45:24 +0100 (MET) | From | "Michael Kerrisk" <> | Subject | Re: 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/
| |