/tmp with the noexec,nodev,nosuid set of options. This is generally presented as one element of a 'defense-in-depth' strategy, by preventing the escalation of an attack that lets someone write a file, or an attack by a user with a legitimate account but no other writable space.Over time, however, I've encountered arguments (most prominently by Debian/Ubuntu Developer Colin Watson) that
noexec is a useless measure, for a couple potential reasons:- The user can run
/lib/ld-linux.soin an attempt to get the same effect. - The user can still run system-provided interpreters on scripts that can't be run directly
debconf likes an executable temporary directory), and the potential loss of convenience, is this a worthwhile security measure? What other holes do you know of that enable circumvention?Answers
Here are the arguments for utility I've come up with so far:
Modern kernels fix the/lib/ld-linux.so hole, so that it won't be able to map executable pages from a noexec filesystem.The interpreters point is certainly still a concern, though I think less of one than people might claim. The reasoning I can come up with is that there have been numerous privilege escalation vulnerabilities that relied on making particular malformed syscalls. Without an attacker providing a binary, it would be much harder to make evil syscalls. Also, script interpreters should be unprivileged (I know this has historically sometimes not been the case, such as with an suid perl), and so would need their own vulnerability to be useful in an attack. Apparently, it is possible to use Python, at least, to run some exploits.
Many 'canned' exploits may try to write and run executables in
/tmp, and so noexec reduces the probability of falling to a scripted attack (say in the window between vulnerability disclosure and patch installation).Thus, there's still a security benefit to mounting
/tmp with noexec.REFERENCES
http://serverfault.com/questions/72356/how-useful-is-mounting-tmp-noexec
