Detecting and controlling unauthorized shared memory reads

Question

Hi all,

I was wondering - are there any known techniques to control access to a shared memory object from anywhere but an authorized program?

For instance, lets say I create a shared memory segment for use in a program P, to be accessed by Q, and I make it Read-Write. I can access it using Q because I've given it (Q) the required permissions to do so (running as a particular user with groups, etc).

However, I'm guessing there are instances where someone could potentially access this shared memory from a program R - simply attaching to it and modifying it. To stop this, you could make the memory segment read only - but now program R could still read what was in the memory.

My question is in parts -

1. Is there a way to,

   a) allow only Q to access the shared memory?

   b) figure whether a read was done by someone apart from Q - and who did it? [Is this even possible?] For bonus points, could this be done cross-platform? [Probably not, but no harm trying :)]

2. Under what circumstances could a rogue program attach to the shared memory? I presume one way is if a user is able to exploit OS holes and become the user that started the program. Any others?

Thanks!

Answer 1

POSIX shared memory has the same permissions system as files - if you run ipcs you'll see the permissions of the shared memory segments on your system:

$ ipcs -m
IPC status from <running system> as of Tue Jul 14 23:21:25 BST 2009
T     ID     KEY        MODE       OWNER    GROUP
Shared Memory:
m  65536 0x07021999 --rw-r--r--     root    wheel
m  65537 0x60022006 --rw-r--r--     root    wheel

In answer to question 1a), you can use the normal UNIX permissions system to only allow access from a certain user and/or group. This can be controlled using shmctl :

struct ipc_perm perms;
perms.uid = 100;
perms.giu = 200;
perms.mode = 0660; // Allow read/write only by 
                   // uid '100' or members of group '200'
shmctl(shmid, IPC_SET, &perms);

For 1b), I don't think any auditing interfaces exist for shared memory access.

With regards to your second question, any process running as the shm owner/group, or running as root will be able to access your memory - this is no different to accessing any other resource. Root can always access anything on a *ix system; and so any exploit which escalated a user to root would allow access to any shared memory region.