Securing the /tmp folder?

11 posts / 0 new
Last post
#1 Sat, 03/12/2011 - 22:30

Securing the /tmp folder?


I'm trying to make my /tmp folder not allow program execution.

My / partition is on a software raid 5, which I guess is /dev/md1, /boot being /dev/md0

Since I'm quite intellectually challenged, I don't quite have the mount thing down- but I had hoped that if I add this line to fstab:

/dev/md1 /tmp ext3 nosuid,noexec,bind 0 0

then reboot, that'd be fine... but... no...

I'm hesitant to follow the online guides because of my RAID scenario and because I'm not crystal clear on what I'm doing, darnit.

If my drive space is completely allocated already, and software RAIDED, how can I safely secure my temp folder?


Sun, 03/13/2011 - 05:38

If /dev/md1 is already mounted as your root filesystem, you cannot mount it again as /tmp. That is like trying to save different data in the same file at the same time and would immediately destroy your root file system (and your installation along with it). :)

Aside from that, the method with the "noexec" flag in fstab is indeed the right way to go. You just need another partition which you can mount for /tmp.

Do you have free partition space on your drives? Or are you maybe using LVM?

If not, you can either try to resize an existing partition to make room for the /tmp one (can be tricky and needs booting from a live CD to resize the / filesystem - dangerous, don't do that without making a good backup first).

Or you can create a file that's going to hold the file system for /tmp and mount it via the loop device instead of an actual HDD partition. (Yes, Linux quite rocks, it can actually mount a file as if it was a disk partition. :) )

This will mean a little degradation in disk IO performance though, since the accesses need to go through "two levels" instead of directly to the disk. Here's an exemplary forum post explaining how to do that:

Sun, 03/13/2011 - 09:32 (Reply to #2)

Disk io speed reduction is the worst possible thing. 

If I have to, I'll reinstall Linux... Which is a huge pain because it takes me hours to reset all the tweaks, websites, scripts, etc. If I DO have to go that way, I have no idea how big /tmp and /var/tmp should be. These are three 120gb disks with:

Swap= 10gb per disk 

/boot = raid 1 across all three

/ = raid 5 across all three

Is a "live disk" simply a version of Linux that will run from the DVD without having to be installed? If so, what's a good Linux utility to repartition a raid 5 software partition? Ummm it ain't sounding likely

Thanks for all your help,


Sun, 03/13/2011 - 11:26

So, for all that trouble -- are you sure you're gaining something you need by setting /tmp to noexec? :-)

On a shared hosting system -- most users on your system can already execute any files they want from their own home directory.

However, all setting /tmp to noexec will prevent is compiled programs from executing.

A large number of malicious apps are written in scripting languages, such as Bash, Perl, PHP, and the like. And those will run just fine out of /tmp even when noexec is set -- because the script isn't considered to be what's executing, it's instead considered to be a parameter to the Bash or Perl or PHP binary.

Personally, I'm not sure that I feel those steps are worth the trouble you may run into in implementing it :-)

There are those who like having that as part of their security setup though... however, I don't know how to do that without either repartitioning, or mounting it as a file using a loopback device


Sun, 03/13/2011 - 11:37 (Reply to #4)

There were some files in the tmp folder on another machine and that machine was generating a lot of naughty outbound DDOS traffic. I'm certain (almost) that those files were put there with some type of php buffer overflow from a hosted website. Moving tmp to another partition and adding noexec put a stop to it on that machine instantly... so, I think it's probably a good idea until I think of something better (like finding the hole that allowed it to happen in the first place, right? hehe).

BUT, I'm curious... I added this line and it works fine:

tmpfs /dev/shm tmpfs nosuid,noexec,nodev,rw 0 0

Couldn't I just make /tmp and /var/tmp symbolic links to /dev/shm?

How big do these tmp folder need to be if I DO have to reinstall with a new partitioning scheme?

Sun, 03/13/2011 - 11:47

The "tmpfs" you're seeing is a RAM-based filesystem.

You can use that if you like, but it costs you your RAM :-) You can read about that here:

As far as how large to make /tmp -- I'm not sure what the current requirements for a /tmp partition are, so I unfortunately don't know :-) You may have to experiment a bit... (or Google around for what other folks think)

Also, you'd likely need to change Webmin's tmp directory (in Webmin -> Webmin Configuration -> Advanced Settings), as it uses /tmp for all of it's backups. That can require quite a bit of space, so unless you make /tmp rather huge, you may just want to select a different Webmin tmp dir.


Sun, 03/13/2011 - 12:25

Ok - thanks... I can't help but ask... if I made /tmp a symbolic link to /dev/shm and shm reached 50% of physical ram (or whatever the default limit is), wouldn't shm just expand and page to the swap partition while maintaining the same privilege set?

... and thus make the world safe for my nightly Webmin backups?

Sun, 03/13/2011 - 12:37

How well it'll work for you depends on how large your backup set is. Some servers have quite a few GB's though, and swapping that all out could cause your disk to begin thrashing. I'd be a bit reluctant to put /tmp on a RAM-based filesystem :-) (but then, I'd also be reluctant to put it on it's own partition)

However, you can tweak how all that works through various mount options. You may just need to experiment a bit :-)

You can see some tmpfs mount options here:

As well as in the "tmpfs" section of the man page for mount.

I can't really offer any advice on how best to make all this work, I've never tried it before :-)


Sun, 03/13/2011 - 13:48 (Reply to #8)

Thanks for all your input. I feel I must lock down the /tmp and /var/tmp and /dev/shm folder because, as far as I can tell, it does indeed effectively stop execution of scripts stored in those folders.

Here's what I'm going to try on one of my servers' fstab:

tmpfs /tmp tmpfs nosuid,noexec,nodev,rw 0 0
tmpfs /var/tmp tmpfs nosuid,noexec,nodev,rw 0 0
tmpfs /dev/shm tmpfs nosuid,noexec,nodev,rw 0 0

My understanding is I could have set the max size, eg.,

tmpfs /var/tmp tmpfs size=2048m,nosuid,noexec,nodev,rw 0 0

but, I'm gambling that shm is set to 50% of the physical ram in CentOS AND that when full, it will page over to the swap partition. If I'm right, on my machine there will be up to 4 Gigs of RAM to be shared amongst /dev/shm, /tmp, and /var/tmp which when full will page over to swap - which on my machine is 30gigs striped on 3 drives. It is indeed possible that some amount of thrashing will occur, but, I'm suspecting that will happen mostly at midnight UTC -7 while my traffic is reltively low and that otherwise, won't be so bad (fingers crossed).

Another serious concern I have is that, if I understand correctly, /var/tmp is supposed to be persistent between boots... ehh.... but, hey they don't call it tmp for nothin' and I'm too lazy to reinstall all this if I don't have too.

I'll post the results of how well it worked out-



Fri, 06/10/2011 - 15:03 (Reply to #9)

Believe it or not, there are some installers that must run out of /tmp and won't install. So, you may encounter some problems with installing new stuff once you "secure" /tmp, and, may have to unsecure it to install certain software. Can't remember examples off hand.

Wed, 06/08/2011 - 19:49

Hi all, I did what I said I would do above, securing the tmp, /var/tmp, and /dev/shm areas.

So far, I've setup three production servers pretty much problem free.

There's a more detailed writeup at

Although this has been working with no real issues for months now, It's definite not an optimal solution. I do consider this as a real problem, but I'm not sure of a tighter solution.

Topic locked