jump to navigation

Secure /tmp – /var/tmp And /shm Directories On CentOS Linux February 23, 2011

Posted by Tournas Dimitrios in Linux.

Keep you server clean of rookits is a good idea to get a good security level. A sys-administrator can create a separate partition for /tmp and mount it with noexec and nosuid parameters. And to do it is not necessary to reboot or repartition your drive.

First step : Securing  /tmp :

  • Make a 1GB file for /tmp and parition and an ext3 filesystem for tmp:
    # dd if=/dev/zero  of=/dev/tmpFS  bs=1024   count=1000000
    # /sbin/mkfs.ext3    /dev/tmpFS
  • Create a backup copy of your current /tmp drive:
    # cp  -Rpf  /tmp  /tmpbackup
  • Mount our new tmp parition and change permissions:
    # mount  -o  loop,noexec,nosuid,rw  /dev/tmpFS  /tmp
    # chmod   1777   /tmp
  • Copy the old data:
    cp  -Rpf /tmpbackup/.*   /tmp/ (note the dot)
  • Edit /etc/fstab and add this:
    /dev/tmpMnt   /tmp    ext3   loop,nosuid,noexec,rw  0 0
  • Test your fstab entry:
    # mount  -o remount  /tmp
  • Run a script on /tmp partition , if you get “permission denied” it is fine

Second step : Securing  /var/tmp : It should be done because some applications use /var/tmp as the temporary folder, and anything that’s accessible by all, needs to be secured.

  • Rename it and create a symbolic link to /tmp:
    # mv  /var/tmp  /var/tmp1
    # ln  -s  /tmp  /var/tmp
  • Copy the old data back:
    # cp  /var/tmpold/*  /tmp/
  • Restart all services that uses /tmp partition (Appache , Ftp …)

Third step : Securing  /dev/shm : To get all the work well done, you should secure /dev/shm to stop rootkits running here.

/dev/shm is an implementation of traditional shared memory concept. It is an efficient means of passing data between programs. One program will create a memory portion, which other processes (if permitted) can access. This will result into speeding up things on Linux.  shm / shmfs is also known as tmpfs, which is a common name for a temporary file storage facility on many Unix-like operating systems. It is intended to appear as a mounted file system, but one which uses virtual memory instead of a persistent storage device.

  • Edit your /etc/fstab:
    vi  /etc/fstab
    “none /dev/shm tmpfs defaults,rw 0 0” to
    “none /dev/shm tmpfs defaults,nosuid,noexec,rw 0 0”
  • Remount /dev/shm:
    # mount  -o  remount  /dev/shm


1. Marco - October 29, 2011

I see this exact same procedure for securing /tmp on recommended on many sites, albeit sometimes with a different size.

There is 1 thing i keep wondering about thought: If the current /tmp already has (a lot of) data in it, wouldn’t that stay for ever in the / filesystem in an inaccessible (as it will be masked by the mount) directory named /tmp?

tournasdimitrios1 - October 29, 2011

The new partition is mounted with :
1) noexec –> Do not allow execution of any binaries on the mounted file system
2) nosuid –> Do not allow set-user-identifier or set-group-identifier bits to take effect
3) chmod 1777 : A file in a sticky directory may only be removed or renamed by a user if the user has write permission for the directory and the user is the owner of the file, the owner of the directory, or the super-user. This feature is usefully applied to directories such as /tmp which must be publicly writable but should deny users the license to arbitrarily delete or rename each others’ files.

In order to prevent the /tmp directory from becoming cluttered or filled with unused files , Linux (CentOs) automatically “sweeps” the /tmp (and a few other) directories . Any files not accessed for a specified amount of time (10-days) are removed .
On a daily bases ( /etc/cron.daily/ **** ) runs “tmpwatch” . This script runs /usr/sbin/tmpwatch -umc – – force
The /etc/cron.daily/tmpwatch task is supposed to manage /tmp for you. Take a look at the script, it should not be difficult to modify it to better suit your needs . Make a copy of it before you edit it though in case you hose it up

Or you could even consider using a tmpfs.

2. Marco - October 30, 2011

Thank you for your response, but i think you mis-understood what i am trying to say.

Let me give an example:
Create a directory /somedir/testdir
Create a file name ‘testfile1’ in this directory.
Now create a filesystem and mount it over /somedir/testdir
Create 1 or more files in the mounted directory.
If you do a ‘ls’ on the mounted directory, you will not see ‘testfile1’ anymore, you will only see the files that have been created after it was mounted.
Now unmount it again.
If you now do a ls of /somedir/testdir, the file testfile1 is “back” again.

This is because the original directory is not removed when you mount a file system over it, but it more functions like a re-direct preventing you to see the original contents of the directory. Once it is unmounted again the “re-direct” is removed and you have access to the original contents of the directory.

This means that the original contents of the directory are never removed from disk when a filesystem is mounted over it. Consider an existing /tmp directory with large amount of data in it. This data would never be removed from disk, taking up space.

(PS I have actually not really tested this on CentOS, but i know that is how the Unix systems i used to work on behaved, and i can not imagine CentOS would do any different.)

tournasdimitrios1 - October 30, 2011

In Linux (and Unix) , the term file has a very general meaning : anything that exists in the filesystem is a file . This includes regular files / directories , hard / soft links (symbolic links) , device nodes , interprocess communications (sockets) .
All files have common attributes: user owner , group owner, permissions, and timing information (Change / modify / last-access date ). This information (meta-data) is stored in a structure called an inode . Linux associates three components with each file : the actual data , meta-data and the file-name (denty) . Although these components reside on the same partition (file-system) , they are positioned on different locations (blocks ) and linked with each other through pointers . Re-mounting a file-system to a new mount-point or deleting a file actually removes these pointers , but the actual data-componetns still exists on the file-system until a new data-component will over-ride its blocks . This all depends on the create / delete cycle of the computer and the partition size of the file-system . Probably a hard-working server will over-ride these data-components much sooner than a home computer . The obvious step before re-mounting a file-system is to back-up its data .
Notice : I skipped many details and focused only on the general concepts . You gave me the idea for a future article “The Linux Filesystem ” . Thanks for your comments .

3. Marco - October 30, 2011

My whole point is that the inode entries for the (original) directory do not get removed when you mount a filesystem over it.

Hard working server or not, the original files (and the inode entries to all files in the /tmp directory) will never get removed. They will exist for ever hidden (but taking up disk space) until the filesystem is unmounted again.

Try the basic example i gave in my previous reply and you will see it.

But you are right we are going far from the original article with this discussion. Feel free to send me an email (i assume you can see that) if you want to further discuss this.


4. tournasdimitrios1 - October 30, 2011

Yes ofcourse , a filesystem that is mounted on top of another , makes the underlying filesystem useless . The underlying filesystem preserves it’s structure , occupies disc-space but it can’t be used any more . Although all files still exists on the underlying filesystem they are un-visible , un-accessible and useless . .

5. Marco - October 30, 2011

My original point was that by mounting on a directory (/tmp) that still contains files you are wasting diskspace.

PS The underlying files are not useless, they can still be accessed once the filesystem is unmounted.

tournasdimitrios1 - October 30, 2011

nice , thanks for stopping on my blog .
I enjoyed this e-conversation 🙂

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s