Plash and the Unix security model
Plash's security model is quite different from the standard Unix security model, and so the two can interact in ways that are not immediately obvious.
The Unix model is based on labelling of objects, and is less concerned with the path taken to get to an object. In contrast, Plash's model, like the capability model, is based on the path of access (disregarding labels on objects).
There are some cases where Plash must be careful not to create security holes in the case where a hostile Plash-sandboxed process conspires with a hostile process running under another Unix user account.
Setuid executables
Potential attack:
- Processes A and B are conspiring and can access a shared directory.
- Process A is running in a sandbox created by user U. Process B is running unsandboxed under another user's account.
- Process A creates an executable file and makes it setuid. Although A cannot run the executable as setuid (because it is running under Plash and Plash does not support invoking setuid executables), B can invoke the executable. A can therefore give B the ability to run arbitrary code with U's authority.
Resolution: Plash does not allow sandboxed programs to set the setuid or setgid bits. Implemented in Plash 1.17.
The hard-link problem
Potential attack:
- Process A is running in a sandboxed created by user U. Process B is running unsandboxed under another user's account.
- Assume that A has been granted write access to /tmp, but not to U's home directory.
- Process B hard links user U's ~/.bashrc file into /tmp. Although process B cannot modify the file -- because, we assume, it is not world writable, and neither is U's home directory, and both are owned by U -- process A can modify it. We cannot distinguish the file from one linked into /tmp by U.