Manfred, Hugh,
While studying the RLIMIT_MEMLOCK stuff further, I came
up with another observation: a process can perform a
shmctl(SHM_LOCK) on *any* System V shared memory segment,
regardles of the segment's ownership or permissions,
providing the size of the segment falls within the
process's RLIMIT_MEMLOCK limit.
Is this intended behaviour? For most other System V IPC
"ctl" operations the process must either:
1. be the owner of the object or have an appropriate
capability, or
2. have suitable permissions on the object.
Which of these two conditions applies depends on the
"ctl" operation.
Cheers,
Michael
--
NEU +++ DSL Komplett von GMX +++ http://www.gmx.net/de/go/dsl
GMX DSL-Netzanschluss + Tarif zum superg?nstigen Komplett-Preis!
On Wed, 24 Nov 2004, Michael Kerrisk wrote:
>
> While studying the RLIMIT_MEMLOCK stuff further, I came
> up with another observation: a process can perform a
> shmctl(SHM_LOCK) on *any* System V shared memory segment,
> regardles of the segment's ownership or permissions,
> providing the size of the segment falls within the
> process's RLIMIT_MEMLOCK limit.
That's a very good observation.
I think it's unintended, but I'm not sure.
I've forgotten what can_do_mlock on shm was about.
Offhand I find it hard to grasp whether it's harmless or bad,
but inclined to think bad - if there happen to be lots of small
enough shared memory segments on the system, a series of processes
run by one unprivileged user can lock down lots of memory?
Isn't it further the case that any process can now SHM_UNLOCK
any segment? That would surely be wrong.
I've added Rik and Chris to the CC list, they seem to be the
main can_do_mlock guys, hope they can answer.
Hugh
> Is this intended behaviour? For most other System V IPC
> "ctl" operations the process must either:
>
> 1. be the owner of the object or have an appropriate
> capability, or
>
> 2. have suitable permissions on the object.
>
> Which of these two conditions applies depends on the
> "ctl" operation.
On Wed, 24 Nov 2004, Hugh Dickins wrote:
>> regardles of the segment's ownership or permissions,
>> providing the size of the segment falls within the
>> process's RLIMIT_MEMLOCK limit.
> Offhand I find it hard to grasp whether it's harmless or bad,
> but inclined to think bad - if there happen to be lots of small
> enough shared memory segments on the system, a series of processes
> run by one unprivileged user can lock down lots of memory?
Mlocking and munlocking of shm segments is accounted
against the user_struct, not against the process.
This should stop any malicious exploits.
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan
Hugh,
> On Wed, 24 Nov 2004, Michael Kerrisk wrote:
> >
> > While studying the RLIMIT_MEMLOCK stuff further, I came
> > up with another observation: a process can perform a
> > shmctl(SHM_LOCK) on *any* System V shared memory segment,
> > regardles of the segment's ownership or permissions,
> > providing the size of the segment falls within the
> > process's RLIMIT_MEMLOCK limit.
>
> That's a very good observation.
Thanks.
> I think it's unintended, but I'm not sure.
> I've forgotten what can_do_mlock on shm was about.
can_do_mlock() returns true if we have CAP_IPC_LOCK
or RLIMIT_MEMLOCK != 0.
> Offhand I find it hard to grasp whether it's harmless or bad,
> but inclined to think bad - if there happen to be lots of small
> enough shared memory segments on the system, a series of processes
> run by one unprivileged user can lock down lots of memory?
>
> Isn't it further the case that any process can now SHM_UNLOCK
> any segment?
I hadn't got as far as thinking about that, but you are
correct. Anyone can SHM_UNLOCK a System V shared memory
segment on 2.6.9, regardless of ownership and permissions.
> That would surely be wrong.
Agreed.
Cheers,
Michael
> I've added Rik and Chris to the CC list, they seem to be the
> main can_do_mlock guys, hope they can answer.
>
> Hugh
>
> > Is this intended behaviour? For most other System V IPC
> > "ctl" operations the process must either:
> >
> > 1. be the owner of the object or have an appropriate
> > capability, or
> >
> > 2. have suitable permissions on the object.
> >
> > Which of these two conditions applies depends on the
> > "ctl" operation.
>
--
Geschenkt: 3 Monate GMX ProMail + 3 Top-Spielfilme auf DVD
++ Jetzt kostenlos testen http://www.gmx.net/de/go/mail ++
Rik,
> On Wed, 24 Nov 2004, Hugh Dickins wrote:
>
> >> regardles of the segment's ownership or permissions,
> >> providing the size of the segment falls within the
> >> process's RLIMIT_MEMLOCK limit.
>
> > Offhand I find it hard to grasp whether it's harmless or bad,
> > but inclined to think bad - if there happen to be lots of small
> > enough shared memory segments on the system, a series of processes
> > run by one unprivileged user can lock down lots of memory?
>
> Mlocking and munlocking of shm segments is accounted
> against the user_struct, not against the process.
>
> This should stop any malicious exploits.
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.
(Also, I just want to reemphasise that these semantics
are inconsistent with the types of ownership and
permission checking performed for just about
every other kind of System V "ctl" operation.)
Cheers,
Michael
--
Geschenkt: 3 Monate GMX ProMail + 3 Top-Spielfilme auf DVD
++ Jetzt kostenlos testen http://www.gmx.net/de/go/mail ++
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 ++
Rik,
> On Thu, 25 Nov 2004, Michael Kerrisk wrote:
>
> > I don't think this is sufficient -- there must
> > be protection against arbitrary SHM_LOCKs.
>
> Why? We already have ulimits do that...
My gut feeling is that processes should not be able to
arbitrarily lock shared memory segments created by other
users in memory. I mean: why should I be able to
someone else's segment into shared memory when I
can't even access the contents of that shared memory.
(Such semantics are simply inconsistent with the
System V IPC model.)
Also (more below), I don't see any other sensible
semantics for these operations, other than the ones
I've proposed.
> > 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.
>
> It makes a lot of sense, but I don't know whether or not
> it'd break any applications...
There is no reason why it should. In 2.6.8, the only
processes that could lock shared memory segments were those
with CAP_IPC_LOCK. Unprivileged processes did not get a
look in.
2.6.9 changed things, but it is very unlikely that
any applications depend on this (yet). Most userland
developers are probably not even aware of the changed
semantics in 2.6.9. The time to repair these
semantics is *now*, before someone does depend
on them. (In any case changes are required, since
at a minimum, SHM_UNLOCK must be repaired.)
You earlier suggested the idea that SHM_UNLOCK
might check to see if the process's user ID matched
that of the process that did the SHM_LOCK. This
doesn't work. Suppose someone else locks *my* segment
(even though they don't have permission to access its
contents or perform other "ctl" operations on it like
IPC_RMID). Under your idea, I would not be able to
do a SHM_UNLOCK to remove that lock.
Cheers,
Michael
--
Geschenkt: 3 Monate GMX ProMail + 3 Top-Spielfilme auf DVD
++ Jetzt kostenlos testen http://www.gmx.net/de/go/mail ++
On Thu, 25 Nov 2004, Michael Kerrisk wrote:
> I don't think this is sufficient -- there must
> be protection against arbitrary SHM_LOCKs.
Why? We already have ulimits do that...
> 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.
It makes a lot of sense, but I don't know whether or not
it'd break any applications...
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan
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
or
2) the process has the correct capabilities set
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan