Hardening Shared Memory (/run/shm) Against Binary Execution

On a Linux system, shared memory (typically mounted at /dev/shm or /run/shm) is a temporary filesystem (tmpfs) used for efficient inter-process communication. Because it resides in RAM, it is extremely fast. However, by default, it often allows the execution of binaries. Attackers frequently use this world-writable location to drop and execute malicious payloads or exploit kits. Hardening this mount point is a critical step in securing your Hovixa VPS.

1. The Risk of Executable Shared Memory

Many exploits rely on the ability to write a binary to a temporary directory and then execute it. While /tmp and /var/tmp are common targets, /dev/shm is often overlooked by administrators. By applying mount options, we can instruct the kernel to refuse execution requests from this specific memory segment.

2. Verifying Current Mount Options

Before making changes, check how your shared memory is currently mounted. Look for the rw (read-write) flag and the absence of security restrictions.

# Check the mount status of shared memory
mount | grep /shm
    

Example output: `tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)`

3. Applying the Hardening Flags

To secure the partition, we need to ensure the following three flags are applied:

• noexec: Prevents binaries from being executed on this filesystem.
• nosuid: Disables set-user-identifier or set-group-identifier bits from taking effect.
• nodev: Prevents the creation of character or block special devices.

Implementation via /etc/fstab

To make the changes persistent across reboots on your Hovixa VPS, edit the /etc/fstab file. If an entry for tmpfs on /dev/shm does not exist, you must add it.

# Edit the fstab file
sudo nano /etc/fstab

# Add or modify the line to match this:
tmpfs /dev/shm tmpfs defaults,noexec,nosuid,nodev 0 0
    

4. Remounting and Testing

Once saved, you can apply the changes immediately without a reboot by remounting the partition.

# Remount shared memory
sudo mount -o remount /dev/shm

# Verify the changes
mount | grep /dev/shm
    

Verification Test:

Try to copy a simple binary (like ls) to /dev/shm and run it. It should return a "Permission denied" error, even if the file has execute permissions.

cp /bin/ls /dev/shm/
chmod +x /dev/shm/ls
/dev/shm/ls
# Result: bash: /dev/shm/ls: Permission denied
    

5. Technical Implementation Details

• Compatibility Issues: Some specialized applications (e.g., certain database engines or older versions of Chrome/Chromium) might require execution in shared memory. If an application fails after this change, check your logs for "Permission denied" errors.
• Systemd Path: On modern Ubuntu/Debian systems, /dev/shm is often a symbolic link to /run/shm. Hardening one usually covers both, but it is best practice to verify the actual mount point in /proc/mounts.
• Tmpfs Flexibility: Because tmpfs is dynamic, it only consumes the RAM it is currently using. Setting these flags does not impact memory efficiency, only security.

Sysadmin Advice: Apply these same noexec,nosuid,nodev flags to `/tmp` and `/var/tmp` for a comprehensive hardening strategy. This creates a "no-run" zone for attackers throughout your temporary directories.