noexec,nodev,nosuidset 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
noexecis 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
debconflikes 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?
Here are the arguments for utility I've come up with so far:Modern kernels fix the
/lib/ld-linux.sohole, so that it won't be able to map executable pages from a
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
noexecreduces 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