2

on RHEL/CentOS 7.9 there is by default tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,seclabel)

A security rule says that it must be mounted with the secure options of nosuid, nodev, and noexec.

Why does RHEL not automatically include noexec when it is already using the other two?

Is it a good idea or bad idea (with explanation) to use the noexec option for /dev/shm specifically? And if it is a good idea how do you go about making it happen, because a corresponding mount statement is not in /etc/fstab

reference: U_RHEL_7_V3R6_STIG_SCAP_1-2_Benchmark.zip

Anyone on the internet can download it from https://public.cyber.mil/stigs/downloads/ under operating systems / redhat7 and read the following:

Rule Title: The Red Hat Enterprise Linux operating system must
            mount /dev/shm with secure options.

Discussion: The "noexec" mount option causes the system to not execute
            binary files. This option must be used for mounting any file
            system not containing approved binary files as they may be
            incompatible. Executing files from untrusted file systems 
            increases the opportunity for unprivileged users to attain 
            unauthorized administrative access.


The "nodev" mount option causes the system to not interpret character or
block special devices. Executing character or block special devices from 
untrusted file systems increases the opportunity for unprivileged users 
to attain unauthorized administrative access.


The "nosuid" mount option causes the system to not execute "setuid" and 
"setgid" files with owner privileges. This option must be used for 
mounting any file system not containing approved "setuid" and "setguid" 
files. Executing files from untrusted file systems increases the 
opportunity for unprivileged users to attain unauthorized administrative 
access.


Check Text: Verify that the "nodev","nosuid", and "noexec" options are
            configured for /dev/shm:


cat /etc/fstab | grep /dev/shm


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


If results are returned and the "nodev", "nosuid", or "noexec" options
are missing, this is a finding.


Verify "/dev/shm" is mounted with the "nodev", "nosuid", and "noexec" 
options:  mount | grep /dev/shm


tmpfs on /dev/shm type tmpfs (rw,nodev,nosuid,noexec,seclabel)


If /dev/shm is mounted without secure options "nodev", "nosuid", and 
"noexec", this is a finding.


Fix Text: Configure the system so that /dev/shm is mounted with the
          "nodev", "nosuid", and "noexec" options by adding /modifying 
          the /etc/fstab with the following line:


tmpfs /dev/shm tmpfs defaults,nodev,nosuid,noexec 0 0
ron
  • 6,575
  • "A security rule says that ..." what "security rule"? "And if it is a good idea" it's a stupid idea to mount any tmpfs noexec, because it does not serve any purpose. noexec is only meant for media filesystem like those from cds and usb-sticks. –  Sep 24 '21 at 06:05
  • Security Technical Implementation Guideline (STIG) rule V-81013 / SV-95725r2_rule; https://www.stigviewer.com/stig/red_hat_enterprise_linux_7/2019-03-08/finding/V-81013 – ron Sep 27 '21 at 12:16
  • description : The "noexec" mount option causes the system to not execute binary files. This option must be used for mounting any file system not containing approved binary files as they may be incompatible. Executing files from untrusted file systems increases the opportunity for unprivileged users to attain unauthorized administrative access. – ron Sep 27 '21 at 12:16
  • If /dev/shm qualifies as an untrusted file system then you’ve got bigger fish to fry than worrying about noexec. The STIG rule only mentions executing binaries, but that’s not the main purpose of exec on /dev/shm. – Stephen Kitt Sep 30 '21 at 21:18
  • https://wiki.archlinux.org/title/Security#File_systems ArchLinux advises to consider using noexec on /dev/shm. – midnite Apr 11 '22 at 16:25

1 Answers1

2

The reason RHEL (in fact, systemd) doesn’t mount /dev/shm with the noexec option is that some software relies on being able to use /dev/shm to execute code. This is perfectly “legal” and standardised: open a shared memory object with shm_open (on Linux, this relies on /dev/shm), and then map it executable with mmap’s PROT_EXEC flag).

If that doesn’t apply to you, you can add the noexec option; the recommended way to do that is to add the appropriate entry in /etc/fstab:

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

Again, this is liable to break well-behaved software. (I hope that whatever security guide or audit is involved here makes that clear.)

See Systemd backed tmpfs | How to specify /tmp size manually for links to relevant systemd documentation. Regarding noexec specifically, see also the discussion in man file-hierarchy.

Stephen Kitt
  • 434,908
  • sounds like a fabulous way to make software in linux not work then have no idea why it doesn't work – ron Sep 23 '21 at 20:21
  • Yes, which is why it should only be done if you know the software you use doesn’t need it (and won’t ever). – Stephen Kitt Sep 23 '21 at 20:34
  • /dev/shm is the file system used to implement the POSIX's shm_open(3) on Linux, so if you break it, you prevent people from creating shared executable pages in a portable way. You obviously don't prevent them from doing that in the first place, you only force them to use non-portable hacks for that. –  Sep 24 '21 at 06:29
  • I hope that whatever security guide or audit is involved here makes that clear; nope. I added to my original post – ron Apr 11 '22 at 16:41