Good Idea / Bad Idea - /dev/shm with nosuid, nodev, and noexec

Joshua Marsh 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
> I'm
> reading is to mount  /dev/shm with nosuid, nodev, and noexec.  I've read
> about
> 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
> other
> 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
> still
> work, can I still run VMs, etc etc)
>
> Something I've noted, While CentOS 5 and 6 don't have this mount options
> for
> /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
that.

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
performance.

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 mailing list