Hard link vulnerability
The following scenario allows another user W to conspire with a sandboxed process P to run code with the authority of the user U that created P's sandbox:
- User W hard links U's ~/.bashrc file into /tmp.
- Process P opens the file in /tmp for writing, and puts malicious code into it.
- When user U next runs bash, the code gets executed with U's authority.
This assumes that
- User U's home directory has the world-execute bit set (but not necessary world-read).
- User U granted P the ability to write to files in /tmp.
Note that user W does not have permission to write to U's ~/.bashrc file.
Reported by Richard Thrippleton (see mailing list post).
Partial solution: deny access to system-wide /tmp
/tmp should be mapped to an empty directory, freshly created for the sandboxed program, rather than being mapped to the system-wide /tmp directory which is shared between users. See Story8.
Possible solutions
In general, it is currently not safe to grant access to directories that are writable by other non-root users.
Some possible changes to Plash to address this are:
- Give a warning or an error when granting access to a directory that's writable by other non-root users. A warning is probably too weak. This would happen at the point of mapping the directory into a namespace, which isn't really the right place. We wouldn't be able to check the subdirectories.
- Give an access error at the point of traversing the directory tree to a directory that's writable by other non-root users. This is simple to implement. However, if Plash is running as root, this would disallow access to all directories owned by normal users, which is not desirable.
- Allow access to directories writable by other non-root users, with the exception of disallowing access to files within them that would not be accessible by the users that can write to the directory. How would this handle groups? Is it possible to implement this without race conditions? Normally the restriction would only apply to files but we would have to extend it to subdirectories on exotic filesystems that allow directories to be hardlinked as well.
Non-solutions
This could be mitigated by not setting the world-execute bit on your home directory. However, this is not practical. It is often necessary to share files with other users. It is typical for HTTP servers to serve the files in ~/public_html. Furthermore, files could have been hard linked before the world-execute bit was unset.
Related problems
This hard-linking issue is also a problem in Unix in the presence of quotas: A malicious user can hard link another user's files, tying up space and thereby exhausting their quota. (This is easy to do if the files were deliberately shared, otherwise the malicious user has to guess filenames.) Here is one discussion about this: http://lists.grok.org.uk/pipermail/full-disclosure/2003-November/014108.html
For Plash this is more serious, because it leaks authority rather than space.