Polyinstantiating /tmp and /var/tmp directories
On Linux systems, the /tmp/ and /var/tmp/ locations are world-writable. They are used to provide a common location for temporary files and are protected through the sticky bit, so that users cannot remove files they don't own from the directory, even though the directory itself is world-writable. Several daemons/applications use the /tmp or /var/tmp directories to temporarily store data, log information, or to share information between their sub-components. However, due to the shared nature of these directories, several attacks are possible, including:
- Leaks of confidential data via secrets in file names.
- Race-condition attacks (TOCTOU) on the integrity of processes and data.
- Denial-of-Service (DoS) attacks based on race conditions and pre-allocating file/directory names.
Polyinstantiation of temporary directories is a proactive security measure which reduces chances of attacks that are made possible by /tmp and /var/tmp directories being world-writable.
Setting Up Polyinstantiated Directories
Configuring polyinstantiated directories is a three-step process (this example assumes that a Red Hat Enterprise Linux 7 system is used):
First, create the parent directories which will hold the polyinstantiation child directories. Since in this case we want to setup polyinstantiated /tmp and /var/tmp, we create /tmp-inst and /var/tmp/tmp-inst as the parent directories.
$ sudo mkdir --mode 000 /tmp-inst
$ sudo mkdir --mode 000 /var/tmp/tmp-inst
Creating these directories with mode 000 ensures that no users can access them directly. Only polyinstantiated instances mounted on /tmp (or /var/tmp) can be used.
Second, configure /etc/security/namespace.conf. This file already contains an example configuration which we can use. In our case we will just uncomment the lines corresponding to /tmp and /var/tmp.
/tmp /tmp-inst/ level root,adm
/var/tmp /var/tmp/tmp-inst/ level root,adm
This configuration specifies that /tmp must be polyinstantiated from a subdirectory of /tmp-inst. The third field specifies the method used for polyinstatiation which in our case is based on process MLS level. The last field is a comma-separated list of uids or usernames for whom the polyinstantiation is not performed1. More information about the configuration parameters can be found in /usr/share/doc/pam-1.1.8/txts/README.pam_namespace.
Also ensure that pam_namespace is enabled in the PAM login configuration file. This should already be enabled by default on Red Hat Enterprise Linux systems.
session required pam_namespace.so
Third, setup the correct selinux context. This is a two-step process. In the first step we need to enable the global SELinux boolean for polyinstantiation using the following command:
$ sudo setsebool polyinstantiation_enabled=1
You can verify it worked by using:
$ sudo getsebool polyinstantiation_enabled
polyinstantiation_enabled --> on
In the second step, we need to set the process SELinux context of the polyinstantiated parent directories using the following commands:
$ sudo chcon --reference=/tmp /tmp-inst
$ sudo chcon --reference=/var/tmp/ /var/tmp/tmp-inst
The above commands use the selinux context of the /tmp and /var/tmp directories, respectively, as references and copies them to our polyinstantiated parent directories.
Once the above is done, you can logoff and login, and each non-root user gets their own polyinstantiation of /tmp and /var/tmp directories.
PrivateTmp feature of systemd
Daemons running on systems which use systemd can now use the PrivateTmp feature. This enables a private /tmp directory for each daemon that is not shared by the processes outside of the namespace, however this makes sharing between processes outside the namespace using /tmp impossible. The main difference between polyinstantiated /tmp and PrivateTmp is that the former creates a per-user /tmp directory, while the latter creates a per-deamon or process /tmp.
Conclusion
In conclusion, while polyinstantiation will not prevent every type of attack (caused by flaws in the applications running on the system, or mis-configurations like weak root password, wrong directory/file permissions etc), it is a useful addition to your security toolkit that is straightforward to configure. Polyinstantiation can also be used for other directories such as /home. Some time ago, polyinstantiated /tmp by default was proposed for Fedora, but several issues caused the proposal to be denied.
-
Default values include the root and the adm user. Since root is a superuser anyway, it does not make any sense to polyinstantiate the /tmp directory for the root user. ↩
Comments
In our environment we have separate FS for /tmp If we configure the polyinstantiation of /tmp to /tmp-inst the "/tmp/inst" falls under root disk and if user put more files in /tmp in his session, then it will load the / file system not the /tmp file system. In that case what to do? I tried configure /tmp to /tmp/tmp-inst to use instead /tmp-inst directory, so that for all users instead of using root partition they will use /tmp. But here i see some weird activities, if test user logged in with new session and what ever files he created is not appearing/listing when he logged in using su - test, viceversa we are seeing. when we create any file from test user using su - test from root will not shown from new or existing session for test.
Please help me to fix, we are using RHEL 7.8
If you are a customer, please file a support ticket for this issue. This needs some investigation.
For selinux beginners like me, can you add : sudo setsebool -P polyinstantiation_enabled=1