2

I am working on hardening a sandbox for student code execution. I think I'm satisfied that students can't share data on the file system or with signals because I've found express rules dictating those and they execute as different unprivileged users. However, I am having a really hard time looking at documentation to determine, when shared memory (or IPC more generally - queues or semaphores) is created, who can see that. If you create shared memory, can anyone on the same machine open it, or is there a way to control that? Does the control lie in the program that creates the memory, or can the sysadmin limit it?

daveagp
  • 2,599
  • 2
  • 20
  • 19

1 Answers1

1

Any process in the same ipc namespace can see and (potentially) access ipc objects created by other processes in the same ipc namespace. Each ipc object has the same user/group/other-rwx permissions as file system objects objects -- see the svipc(7) manual page.

You can create a new ipc namespace by using the clone(2) system call with the CLONE_NEWIPC flag. You can use the unshare(1) program to do a clone+exec of another program with this or certain other CLONE flags.

Chris Dodd
  • 119,907
  • 13
  • 134
  • 226
  • If I am using fork() instead of clone(), do you think I can use unshare() instead with CLONE_NEWIPC? (What a great function name! Makes my question look kind of foolish in retrospect.) – daveagp Sep 27 '14 at 19:45
  • Looks like `unshare` just calls clone+exec with the appropriate flags, so it should do exactly what you want... – Chris Dodd Sep 27 '14 at 19:57
  • Yup it seems to do the trick. The manual warns "unshare() does not implement flags that reverse the effects of CLONE_SIGHAND, CLONE_THREAD, or CLONE_VM" but none of those seem to be relevant to my case. Thank you! – daveagp Sep 27 '14 at 20:50