Warning message

Log in to add comments.

New Red Hat Enterprise Linux 7 Security Feature: PrivateTmp

Daniel Walsh published on 2014-04-09T13:30:19+00:00, last updated 2014-04-09T13:30:19+00:00

One of the reasons I am really excited about Red Hat Enterprise Linux 7 is the amount of new security features we have added, and not all of them involve SELinux.

Today, I want to talk about PrivateTmp.

One of my goals over the years has been to stop system services from using /tmp. I blogged about this back in 2007.

Anytime I have discovered a daemon using /tmp, I have tried to convince the packager to move the temporary content and FIFO files to the /run directory. If the content was permanent, then it should be in /var/lib. All users on your system are able to write to /tmp, so if an application creates content in /tmp that is guessable (i.e., has a well-known name), a user could create a link file with that name in /tmp and fool the privileged app to unlink or overwrite the destination of the link. Not only would you have to worry about users doing this, but you would also have to worry about any application that the user runs and any service that you have running on your system. They are all allowed to write to /tmp based on permissions.

Over the years, there have been several vulnerabilities (CVEs) about this. For example, CVE-2011-2722 covered a case where hplib actually included code like this:

fp = fopen ("/tmp/hpcupsfax.out", "w"); // <- VULN
system ("chmod 666 /tmp/hpcupsfax.out"); // <- "

This means that if you set up a machine running the cups daemon, a malicious user or an application that a user ran could attack your system.

I have convinced a lot of packages to stop using /tmp, but I can't get them all. And in some cases, services like Apache need to use /tmp. Apache runs lots of other packages that might store content in /tmp.

Well, systemd has added a lot of new security features (more on these later).

PrivateTmp, which showed up in Fedora 16, is an option in systemd unit configuration files.

> man system.unit
  A unit configuration file encodes information about a service, 
  a socket, a device, a mount point, an automount point, a  swap
  file or partition, a start-up target, a file system path or a
  timer controlled and supervised by systemd(1).

> man systemd.exec
    systemd.exec - systemd execution environment configuration
    systemd.service, systemd.socket, systemd.mount, systemd.swap
    Unit configuration files for services, sockets, mount points
    and swap devices share a subset of configuration options which
    define the execution environment of spawned processes.
    Takes a boolean argument. If true sets up a new file system
    namespace for the executed processes and mounts a private /tmp
    directory inside it, that is not shared by processes outside of
    the namespace. This is useful to secure access to temporary files
    of the process, but makes sharing between processes via /tmp
    impossible. Defaults to false.

PrivateTmp tells systemd to do the following anytime it starts a service with this option turned on:

   Allocate a private "tmp" directory
   Create a new file system namespace 
   Bind mount this private "tmp" directory within the namespace over
   Start the service. 

This means that processes running with this flag would see a different and unique /tmp from the one users and other daemons sees or can access.

NOTE: We have found bugs using PrivateTmp in Fedora 16, so make sure you test this well before turning it on in production.

For Fedora 17, I opened a feature page that requested all daemons that were using systemd unit files and /tmp to turn this feature on by default.

Several daemons, including Apache and cups, now have PrivateTmp turned on by default in Red Hat Enterprise Linux 7.

Given the three options as a developer of system service, I still believe that you should not use /tmp. You should instead use /run or /var/lib. But if you have to use /tmp and do not communicate with other users, then use PrivateTmp. If you need to communicate with users, be careful....

About The Author

rhn-engineering-dwalsh's picture

Daniel Walsh

Daniel Walsh has worked in the computer security field for over 30 years. Dan is a Consulting Engineer at Red Hat. He joined Red Hat in August 2001. Dan leads the Red Hat Container Engineering team since August 2013, but has been working on container technology for several years. Dan has made m...

Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.