Linux temporary file security

Article Title: Ensure the security of temporary Linux Files. Linux is a technology channel of the IT lab in China. Includes basic categories such as desktop applications, Linux system management, kernel research, embedded systems, and open source.

In a typical Linux system, at least two directories or partitions maintain temporary files. One of them is the/tmp directory, and the other is/var/tmp. In the updated Linux kernel system,/dev/shm may also exist, which is loaded using the tmpfs file system.

There is a problem with directories that store temporary files, that is, these directories can become a hotbed of botnets and rootkits that damage system security. This is because in most cases, anyone (or any process) can write to these directories, and there are also insecure licensing issues. We know that all sticky bits can be understood as anti-delete bits. If you want to add a file but cannot delete the file at the same time, you can use the sticky bit for the file. After this bit is set, the file cannot be deleted even if the user has the write permission on the directory. In most Linux distributions, sticky bits are set in the temporary directory. This means that user A cannot clear A file belonging to user B, and vice versa. However, according to the permission of the file itself, user A may view and modify the content of the file.

In a typical Linux installation,/tmp is set to mode 1777, which means that it sets the sticky bit and can be read, written, and executed by all users. In most cases, this is the same as the security settings, mainly because the/tmp directory is only a directory rather than a file system. The/tmp directory depends on/partition, so that it must follow its loading options.

A safer solution may be to set/tmp on its own partition, so that it can be independent of/partition loading and have more restrictions. An example of the/etc/fstab project in the/tmp partition looks like this:

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

This sets the nosuid, noexec, and nodev options, which means that no suid program is allowed, no content can be executed from this partition, and no device file exists.

You can clear the/var/tmp directory and create a symlink pointing to the/tmp directory. In this way, temporary files in/var/tmp can use these restrictive loading options.

The/dev/shm virtual file system also needs to ensure its security, which can be achieved by changing/etc/fstab. In typical cases,/dev/shm is loaded using the ults option, which is insufficient to ensure its security. Like fstab of/tmp, it should have more restrictive loading options:

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

In a typical Linux system, at least two directories or partitions maintain temporary files. One of them is the/tmp directory, and the other is/var/tmp. In the updated Linux kernel system,/dev/shm may also exist, which is loaded using the tmpfs file system.

Finally, if you cannot create the latest/tmp partition on an existing drive, you can create a loopback file system to use the loopback feature of the Linux kernel, this file system can be loaded as/tmp and can use the same loading restriction option. To create a 1 GB loopback file system, run the following command:

# Dd if =/dev/zero of =/. tmpfs bs = 1024 count = 1000000

# Mke2fs-j/. tmpfs

# Cp-av/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/etc/fstab to automatically load the loopback file system at startup:

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

Ensuring proper licensing and using restrictive cutting options can prevent many damages to the system. If a zombie is installed on an unexecutable file system, it is not worth worrying about in essence.