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
Browse by channel
Automation
The latest on IT automation for tech, teams, and environments
Artificial intelligence
Updates on the platforms that free customers to run AI workloads anywhere
Open hybrid cloud
Explore how we build a more flexible future with hybrid cloud
Security
The latest on how we reduce risks across environments and technologies
Edge computing
Updates on the platforms that simplify operations at the edge
Infrastructure
The latest on the world’s leading enterprise Linux platform
Applications
Inside our solutions to the toughest application challenges
Original shows
Entertaining stories from the makers and leaders in enterprise tech
Products
- Red Hat Enterprise Linux
- Red Hat OpenShift
- Red Hat Ansible Automation Platform
- Cloud services
- See all products
Tools
- Training and certification
- My account
- Customer support
- Developer resources
- Find a partner
- Red Hat Ecosystem Catalog
- Red Hat value calculator
- Documentation
Try, buy, & sell
Communicate
About Red Hat
We’re the world’s leading provider of enterprise open source solutions—including Linux, cloud, container, and Kubernetes. We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.
Select a language
Red Hat legal and privacy links
- About Red Hat
- Jobs
- Events
- Locations
- Contact Red Hat
- Red Hat Blog
- Diversity, equity, and inclusion
- Cool Stuff Store
- Red Hat Summit