Secure temporary files for Linux systems

In a typical Linux system, there are at least two directories or partitions that hold temporary files. One of these is the/tmp directory, and/var/tmp. In the newer Linux kernel system, there may also be/dev/shm, which is loaded with the Tmpfs file system.

The problem with storing temporary files is that these directories can be a hotbed of zombies and rootkit that compromise system security. This is because in most cases, anyone (or any process) can write to these directories, as well as unsafe licensing issues. We know that all sticky bit, this bit can be understood as the anti-deletion bit. If you want users to be able to add files and not delete files at the same time, you can use the sticky bit bit for the file. After this bit is set, the file cannot be deleted even if the user has write permission to the directory. Most Linux distributions set the sticky bit on the temporary directory, which means that user A cannot purge a file that belongs to User B, and vice versa. However, depending on the permissions of the file itself, user A is likely to view and modify the contents of that file.

A typical Linux installation sets/tmp to mode 1777, which means it has a sticky bit set and can be read, written, and executed by all users. In most cases, this is as secure as it is set, primarily because the/tmp directory is only a directory, not a file system of its own. The/tmp directory depends on/partition, so it must also follow its mount options.

A more secure solution might be to set/TMP on its own partition so that it can be loaded independently of/partition, and can have more restrictive options. An example of the/etc/fstab project for the/TMP partition looks like this:

/dev/sda7 /tmp ext3 nosuid,noexec,nodev,rw 0 0

This sets the Nosuid, Noexec, and nodev options, meaning that no suid program is allowed to perform anything from this partition, and no device files exist.

You can clear the/var/tmp directory and create a symlink point to/tmp directory so that temporary files in/var/tmp can take advantage of these restrictive mount options.

The/DEV/SHM virtual file system also needs to be secure, which can be achieved by changing the/etc/fstab. Typically,/DEV/SHM is loaded with the defaults option, which is not enough to guarantee its security. Like the fstab in/TMP, it should have more restrictive loading options:

none /dev/shm tmpfs defaults,nosuid,noexec,rw 0 0

Finally, if you do not have the ability to create an up-to-date/TMP partition on an existing drive, you can use the loopback feature of the Linux kernel by creating a loopback file system that can be loaded AS/TMP and can use the same restricted load option. To create a 1GB loopback file system, you need to perform:

# dd if=/dev/zero of=/.tmpfs bs=1024 count=1000000
# mke2fs -j /.tmpfs
# cp -av /tmp /tmp.old
# mount -o loop,noexec,nosuid,rw /.tmpfs /tmp
# chmod 1777 /tmp
# mv -f /tmp.old/* /tmp/
# rmdir /tmp.old

Once completed, you need to edit the/etc/fstab to automatically load the loopback file system at startup:

/.tmpfs /tmp ext3 loop,nosuid,noexec,rw 0 0

Ensuring proper licensing and the use of restrictive addition options can prevent many damage to the system. If a zombie has a home on a file system that cannot be executed, it is inherently not worth worrying about.