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