Good Idea / Bad Idea - /dev/shm with nosuid, nodev, and noexec
joshua at themarshians.com
Fri Jul 27 17:38:11 MDT 2012
On Fri, Jul 27, 2012 at 5:05 PM, Jacob Albretsen <jakea at xmission.com> wrote:
> I am hardening some CentOS 5 and 6 boxes, and one of the recommendations
> reading is to mount /dev/shm with nosuid, nodev, and noexec. I've read
> what /dev/shm is, but I lack a deeper understanding. I've seen some things
> online talking about it, but nothing concrete as to why it's a good idea
> than "it's more secure". Can anyone enlighten me more about this? I don't
> want to run into any unintended issues down the road (will XYZ services
> work, can I still run VMs, etc etc)
> Something I've noted, While CentOS 5 and 6 don't have this mount options
> /dev/shm by default, Fedora 16 does mount /dev/shm with nosuid,nodev.
It's just shared memory but accessible via typical file methods. It uses
tmpfs to basically make a file system backed by RAM. When you read/write
from it, you are reading/writing directly to memory and you skip the I/O
bottleneck of your HDD (assuming you have enough RAM).
I think nosuid and nodev are fairly standard, so you shouldn't have
problems there. I can't say that noexec would necessarily cause a problem.
I have yet to see an application that writes an executable to /dev/shm and
then runs it. Although that is entirely possible and noexec would break
I've personally never done that using /dev/shm. I think the majority of
people use it as an efficient way to pass data around or for improving
On a side note, if you are into performance, you can put commonly used
things in there to improve speed. I've heard of people putting
chrome/firefox profiles in there or even commonly used config/data files.
Be warned though that you have to copy them back in each time you reboot
because it's not persistent.
More information about the PLUG