danwalsh


Dan Walsh's Blog

Got SELinux?


Previous Entry Share Next Entry
Fedora 17 New Security Feature part II - PrivateTmp
danwalsh
One of the reasons I am really excited about Fedora 17 is amount of new Security Features we have added, and not all of them involve SELinux ...

As  I blogged a few weeks ago, we have stopped the ability for one process to look at another processes memory even if they have same UID, with the deny_ptrace feature.

PrivateTmp

But 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.    Any time I have found out a daemon was using /tmp, I tried to convince the packager to move the content to /run directory if it was temporary or /var/lib if it was permanent. 

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

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

Meaning if you setup a machine running cups daemon, a bad user or a 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 lots 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 causes systemd to do the following any time 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.

Apache and Cups now have PrivateTmp turned on by default in Fedora 17, along will several other daemons.

Giving three options as a Developer of System Service, I still believe that you should not use /tmp, you should 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...

(Deleted comment)

Re: Gnome forks and security

danwalsh

2012-02-24 02:07 pm (UTC)

I don't see why not. I will look at all security issues raised by SELinux.

How to learn the PrivateTmp directory of a service?

http://openid.anonymity.com/bo70ve

2012-12-28 01:21 pm (UTC)

How can I learn which of the gazillion private "tmp" directories created by systemd under /tmp belongs to a given running service? Motivating use case: profiling PHP applications server-side with XDebug. Need to know where the profiler output files end up!

You are viewing danwalsh