/dev/shm is not always mounted with a proper options.

Asked by daniel CURTIS

Hi. A couple of days ago, I've noticed that /run/shm (type tmpfs) is not mounted with options, which I've added to the '/etc/fstab' file. By default /dev/shm (as a matter of fact: /run/shm - is a symlink to /dev/shm) is mounted with: 'defaults' and 'ro'. So according to the Ubuntu StricterDefault wiki page [1], I've added an entry to the '/etc/fstab' file, to mount /dev/shm with e.g. additional 'noexec' option.

According to a second possibilities mentioned in a StricterDefaults document, now three options should be in use: 'nodev', 'nosuid' and 'noexec', right? It is works for some time, but sometimes the /run/shm is mounted once again with only two options: 'nosuid' and 'nodev'. It seems, like Ubuntu ignore a new entry in the '/etc/fstab' file. The most important problem is, that temporary storage directories such as /tmp, /var/tmp and /dev/shm provide storage space for malicious executables.

It is normal? What is the reason, that system sometimes ignore this entry? By "sometime" - I mean a once per five, six system booting. Luckily, this machine is not so important. I'd tests a various things and sometimes this machine is not even connected to the internet. But, this problem is so, important for me.

It is an entry added to the '/etc/fstab' file (according to SctricterDefault page):

,-----[ /etc/fstab with additional option ]
| none /dev/shm tmpfs defaults,noexec,nosuid,nodev 0 0
`-----

With 'noexec' options, system run properly. Nothing happens e.g. with programs etc. Everything is okay. What could be a reason? Could it be a bug?

Best regards.
_____________
[1] https://help.ubuntu.com/community/StricterDefaults

Question information

Language:
English Edit question
Status:
Solved
For:
Ubuntu Edit question
Assignee:
No assignee Edit question
Solved by:
daniel CURTIS
Solved:
Last query:
Last reply:
Revision history for this message
actionparsnip (andrew-woodhead666) said :
#1

What is the output of :

lsb_release -a; uname -a

Thanks

Revision history for this message
daniel CURTIS (anoda) said :
#2

Hi Andrew. It is a Xubuntu 12.04.2 (codename: precise and distribution ID: Ubuntu) with latest 3.2.0-49-generic-pae kernel (i686). I've noticed that in /proc/self/mounts file there is a double entries about '/dev/shm':

,-----[ /proc/self/mounts file ]
| none /run/shm tmpfs rw,nosuid,nodev,relatime 0 0
| none /run/shm tmpfs rw,nosuid,nodev,noexec,relatime 0 0

Similar things are also in the '/proc/self/mountstats' file. As you can see, one entry is related to my settings in the '/etc/fstab' file. But as I already mentioned, I've used /dev/shm. Maybe change it to the /run/shm will be correct? What do you think?

Revision history for this message
daniel CURTIS (anoda) said :
#3

Hi, sorry for a double post, but it seems that changing '/dev/shm' to '/run/shm' in /etc/fstab file was a good decision. Now, thare are not two entries about shm in /proc/self/mounts nad /proc/self/mountstats files. I don't know yet if it will work and a system will be not mounting '/dev/shm/' with two defaults options (see above).

Best regards.

Revision history for this message
daniel CURTIS (anoda) said :
#4

Hi. It seems, that everything is working okay. Best regards.

Revision history for this message
daniel CURTIS (anoda) said :
#5

Three days, without problems. I think it is enough. Best regads.

Revision history for this message
Tomasz Konefal (twkonefal-j) said :
#6

I had this same problem when hardening an image:

No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 14.04 LTS
Release: 14.04
Codename: trusty
Linux img-ults1404-64-h 3.13.0-24-generic #46-Ubuntu SMP Thu Apr 10 19:11:08 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

It seems that trying to mount /dev/shm (which is now a symlink to /run/shm) is the cluprit. Changing the fstab entry as follows has resolved the problem for me, too.

none /run/shm tmpfs rw,nodev,nosuid,noexec 0 0

Revision history for this message
daniel CURTIS (anoda) said :
#7

Hi Tomasz. Yes, changing the fstab file entry seems to be a solution for this "issue". Some time ago I created a blueprint related to this: https://blueprints.launchpad.net/ubuntu/+spec/shared-memory

Best regards.