Managing /tmp and /var/tmp, and why not globally writeable?

jpganz18 asked:

Ive been trying to lock some security vulnerabilities at my server, and I got to the point of the tmp folders. Both of them will store files that are used by other resources, still, reading a little more I found out that the /tmp could save some data that involves the server itself instead of the /var/tmp.

My question is, What are the implications of securing write access to /tmp and /var/tmp. I already tried securing /var/tmp and until now nothing bad has happened.

Is it safe to block /tmp and deny saving files that could damage my server or could there be a type of spam or something similar that affects my security? What is the vulnerability if I allow access on my server to these folders, say writeable with 777 permissions (like they come by default)


My answer:

/tmp and /var/tmp were historically well-known locations where programs could store temporary files. However, to function properly they have to be world writable (and sticky). This works, but it also opens up a wide variety of potential security issues with one program writing temporary files that another program will read, thus causing the second program to behave in unexpected and undesirable ways.

The first “fix” for this was to have all programs writing temporary files to use a system call to generate random filenames. This sort of works, but it’s dependent on (1) the program actually using it; (2) having a secure RNG; and (3) luck.

There’s a move on in the Fedora Project to have system services each use an independent private temporary directory accessible only to that service. Each program sees and uses /tmp but they are actually namespaced bind mounts managed by the system. Very clever solution, and one I suspect will start showing up in other Linux distributions soon.

View the full question and answer on Server Fault.

Creative Commons License
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.