Subscribe to our blog

This article was originally published on the Red Hat Customer Portal. The information may no longer be current.

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
  NAME
    systemd.exec - systemd execution environment configuration
  SYNOPSIS
    systemd.service, systemd.socket, systemd.mount, systemd.swap
  DESCRIPTION
    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.
  ...
  PrivateTmp=
    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
   /tmp
   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

Daniel Walsh has worked in the computer security field for over 40 years. Dan is a Senior Distinguished Engineer at Red Hat. He joined Red Hat in August 2001. Dan is the lead architect of the Red Hat Container Runtime Engineering team. Dan has been working on container technologies for 17 years. Dan focusess on the CRI-OvContainer Runtime for Kubernets, Buildah for building container images, Podman for running and managing containers, containers/storage and containers/image. He has led the SELinux project, concentrating on the application space and policy development. Dan helped developed sVirt, Secure Virtualization as well as the SELinux Sandbox. Previously, Dan worked Netect/Bindview's on Vulnerability Assessment Products and at Digital Equipment Corporation working on the Athena Project, AltaVista Firewall/Tunnel (VPN) Products. Dan has a BA in Mathematics from the College of the Holy Cross and a MS in Computer Science from Worcester Polytechnic Institute.
Read full bio

Browse by channel

automation icon

Automation

The latest on IT automation that spans tech, teams, and environments

AI icon

Artificial intelligence

Explore the platforms and partners building a faster path for AI

open hybrid cloud icon

Open hybrid cloud

Explore how we build a more flexible future with hybrid cloud

security icon

Security

Explore how we reduce risks across environments and technologies

edge icon

Edge computing

Updates on the solutions that simplify infrastructure at the edge

Infrastructure icon

Infrastructure

Stay up to date on the world’s leading enterprise Linux platform

application development icon

Applications

The latest on our solutions to the toughest application challenges

Original series icon

Original shows

Entertaining stories from the makers and leaders in enterprise tech