50

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?

Phil Miller
  • 1,725
  • 1
  • 11
  • 17
  • 1
    @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. –  Jan 03 '13 at 17:51
  • VMware's Site Recovery Manager runs scripts from "/tmp": IP Customization fails during a failover or test failover of a recovery plan in vCenter Site Recovery Manager (2021083): http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2021083 –  Aug 25 '15 at 12:50
  • 1
    I know that the compression utility called snappy drops a .so file in /tmp and can't run if it's mounted noexec. (it's used by default in cassandra and kafka) IMHO this is a reason not to use snappy rather than a reason not to mount /tmp noexec – jorfus Jul 21 '17 at 18:32

6 Answers6

36

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.

Phil Miller
  • 1,725
  • 1
  • 11
  • 17
  • 2
    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 09 '09 at 06:56
  • As noted in the manual linked in the question, it does mess with Debconf package pre-configuration without setting up an alternative. – Phil Miller Oct 13 '09 at 18:15
  • 2
    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 05:36
  • 1
    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. – Phil Miller Oct 13 '11 at 15:15
  • It's also a problem with android sdk stuff. Trying to run the graphical android sdk updater will result in `Exception in thread "main" java.lang.UnsatisfiedLinkError: no swt-gtk-3550 or swt-gtk in swt.library.path, java.library.path or the jar file` errors unless /tmp is executable – Mala Feb 04 '13 at 02:07
  • @neoice It is worth it to mention that installing PostgreSQL 9.1.4 will break if this is so. – Sean Allred Jun 14 '13 at 18:35
  • @neoice Oracle Enterprise Manager Agent deployer breaks when /tmp is noexec. – Ekevoo Oct 02 '13 at 13:47
  • Installing nVidia CUDA 5.0 on Ubuntu 12.04 failed when /tmp was mounted with `noexec`. – phylae Dec 18 '13 at 08:01
  • docker-compose fails when /tmp is mounted with noexec – Eiver Aug 31 '20 at 12:22
  • i've been doing lots of python development and here's a list of pip packages that failed to install because `/tmp` is mounted with `noexec`: `scikit-learn`, `matplotlib==1.3.0`, `PyQt4`, `wxpython`. so now i need to do development on a different machine because I can't pip install what is needed on this machine. – Trevor Boyd Smith Dec 03 '20 at 13:32
  • Coq also breaks with noexec `/tmp`: https://github.com/coq/coq/issues/14215. – Blaisorblade Apr 30 '21 at 13:17
  • Just because certain software like postgres and oracle EMA fail doesn't mean you should remove `noexec` from `/etc/fstab`. If your (eg. regulated) env is properly secure, there may not be much to do but hope you can build from source and update it, or bang your head against a brick wall for a couple of weeks. – volvox Jun 13 '22 at 22:06
8

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";};
karmawhore
  • 3,865
  • 17
  • 9
7

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...

Tobu
  • 4,367
  • 1
  • 23
  • 31
thomasrutter
  • 2,437
  • 1
  • 25
  • 34
5

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.

tylerl
  • 14,885
  • 7
  • 49
  • 71
3

First: It covers many, different attack cases. Turning it off because there was a few known ways around it (some of which even fixed) is weird. Attackers downloading code to /dev/shm or /tmp is a common thing they do.

Defense in depth is about securing most common waypoints, each that stops them makes your system more survivable. Not safe. But it'll also have a chance. If they can't fetch their secondary payload, that is a pretty good chance you're getting.

  • It might also be stopped by iptables user restrictions.
  • It might also be stopped by SELinux.
  • It might also not be stopped due to an easily accessed other exploit.

The point is to make it as hard as you easily can, and cut out 99% of the attacks.

Second: It stops bad practice (running stuff from temp, doing major application installs via /tmp instead of a user tmpdir), leaving data in /tmp. Custom installers usually do understand TMPDIR Also: even if not: installation time, as a point-in-time action, is not a valid reason to turn off a security issue permanently.

Third: Considering anonymous namespaces in /tmp (a "feature"), you really want to restrict what's put there and run from there.

Fourth: Convenience is not a relevant factor in this. Assuming we run servers for money, and for a purpose: we're responsible for this stuff. "Oh, I didn't lock down /tmp because then I need a few more minutes when I update my software next year". Surely it'll not be just this one thing that stands between being blackmailed and just being fine. A great reason? I don't think so.

How about this one:

"We learned that enemies can attack without notice. They could also use hundreds of spies to poison the food. So we stopped handing out guns to our soldiers."

Wait, WHAT?

There's other measures that require a lot more effort, experience and luck to secure a system, and knowing people have limited money, lifespans and also would like to spend time with their families: Don't skip the easy stuff.

Anthony Geoghegan
  • 2,800
  • 1
  • 23
  • 34
Florian Heigl
  • 1,440
  • 12
  • 19
1

There are applications that require /tmp to be executable to install. At a previous job, before I got there the admins had set up /tmp noexec, but I discovered that the db2 package wouldn't install. Even if you untar the db2 package somewhere else, the install procedure copies some files to /tmp and expects to be able to execute it, which of course failed with permission denied. If you aren't aware that the filesystem is mounted noexec, it might be a little misleading. It was only able to continue the install after I remounted /tmp without noexec.

Anyway, the point is that at least one commercial product requires /tmp to not be mounted noexec, and there might be others. I haven't found a really compelling reason for it. If you want better security, I would go with selinux instead.

lsd
  • 1,653
  • 10
  • 8
  • 1
    An analysis of an exploit for the Samba vulnerability, which would be stopped by a noexec /tmp: http://bobao.360.cn/learning/detail/4168.html (Chrome's Google translate recommended. It would break the initial exploit, as well as a big part of the payload...) (You can break many common automatic exploits that way....). `mount -o remount,exec /tmp` works when you need to install stuff... (Yes, it is trivial to work around, but many attackers don't seem to bother...) – Gert van den Berg Aug 04 '17 at 10:30