Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

Many people (including the Securing Debian Manual) recommend mounting /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:

  1. The user can run /lib/ld-linux.so <binary> in an attempt to get the same effect.
  2. The user can still run system-provided interpreters on scripts that can't be run directly

Given these arguments, the potential need for more configuration (e.g. 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?

share|improve this question
    
@neoice: I have heard that applications will occasionally break if /tmp is not executable. I've yet to actually see it happen though. Look at TuxGuitar-1.2 ... it happens. Will not start if /tmp isn't mounted without noexec option, because it unpacks libraries there and then tries to load them. –  user151831 Jan 3 '13 at 17:51
add comment

4 Answers

up vote 18 down vote accepted

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.

As described in Debian's bug tracker, setting APT::ExtractTemplates::TempDir in apt.conf to a directory that is not noexec and accessible to root would obviate the debconf concern.

share|improve this answer
    
however, I have heard that applications will occasionally break if /tmp is not executable. I've yet to actually see it happen though. –  neoice Oct 9 '09 at 6:56
    
As noted in the manual linked in the question, it does mess with Debconf package pre-configuration without setting up an alternative. –  Novelocrat Oct 13 '09 at 18:15
1  
Yes, noexec is a very good additional layer to security and I have not seen things braking havoc due it. Package installation is the only thing and even that can be worked around as told by answers here. As my solution I have an alias like this: alias update="mount -o exec,remount /tmp && apt-get update && apt-get upgrade && mount -o noexec,remount /tmp" –  Janne Pikkarainen Aug 30 '10 at 5:36
    
I guess it is uncommon, but packages that are written to execute something from /tmp outside of a package installation context do exist (e.g., the current version of the middleware for using the Belgian Electronic Identity Cards). –  equaeghe Oct 11 '11 at 15:21
    
equaeghe: What package is that? It should probably be reported as a bug. I'm willing to bet there's a security vulnerability to be found in how it's using that, too. –  Novelocrat Oct 13 '11 at 15:15
show 4 more comments

Many Debian packages require /tmp to be executable in order for the package to install. These are often marked as bugs (of 'normal'/'wishlist' severity):

https://www.google.com/#q=site:bugs.debian.org+noexec+/tmp

I received just this error while installing an updated kernel to the stable branch just today.

So it looks like Debian (& derivatives?) is not ready for /tmp to be mounted noexec...

share|improve this answer
add comment

Even though workarounds exist for most supplementary security measures you might choose to implement, even the most easily circumvented security measures (such as mounting /tmp noexec or running SSH on an alternate port) will thwart automated or scripted attacks that rely on the defaults in order to function. It won't protect you against a determined and knowledgeable attacker, but well over 99% of the time, you won't be up against a determined or knowledgeable attacker. Instead, you'll be defending yourself against an automated attack script.

share|improve this answer
add comment

add the following to /etc/apt.conf, or, /etc/apt/apt.conf.d/50remount

DPkg::Pre-Install-Pkgs {"mount -o remount,exec /tmp";};
DPkg::Post-Invoke {"mount -o remount /tmp";};
share|improve this answer
3  
I've replaced mount by /bin/mount in case PATH gets modified. You'll never know. –  Lekensteyn Dec 10 '10 at 15:24
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.