While the man pages provide terse definitions of these mount options, real-world security implications become clear when examining attack scenarios. Let's break down what happens when these protections are missing:

# Vulnerable fstab entry example
tmpfs /mnt/temp tmpfs defaults 0 0

Without nodev, any user with write access can create block/character device files:

$ mknod /mnt/temp/evil_device c 1 3  # Creates /dev/null equivalent
$ mknod /mnt/temp/root_disk b 8 1    # Creates /dev/sda1 equivalent

Attack possibilities include:

• Creating memory access devices like /dev/mem for DMA attacks
• Faking storage devices to intercept I/O operations
• Bypassing filesystem permissions via raw device access

When nosuid is missing, attackers can plant privileged executables:

$ cp /bin/bash /mnt/temp/shell
$ chmod 4755 /mnt/temp/shell  # SETUID root
$ /mnt/temp/shell -p          # Gains root shell

Critical risks include:

• Persistence via cron jobs or startup scripts
• Privilege escalation through vulnerable SUID binaries
• SGID abuse for group privilege attacks

For non-root user accessible mounts:

tmpfs /mnt/secure tmpfs nosuid,nodev,noexec,size=1G,uid=1000,gid=1000,mode=1700 0 0

Key protections:

• nodev: Blocks device file creation
• nosuid: Neutralizes SUID/SGID threats
• noexec: Prevents executable code (bonus protection)
• Strict ownership/mode: Limits access to intended user

Consider a web application with upload directory on vulnerable tmpfs:

1. Attacker uploads malicious SETUID binary
2. Triggers execution via CGI script
3. Gains root through memory corruption in binary

This demonstrates why these mount options are security fundamentals rather than optional hardening measures.

---

When mounting filesystems without nodev, you're allowing the interpretation of block/character special devices. Let's examine what this means in practice:

# Example vulnerable fstab entry without nodev:
tmpfs   /mnt/tmp  tmpfs   defaults   0 0

A malicious user with write access could create device files that allow direct hardware access:

mknod /mnt/tmp/sda1 b 8 1   # Creates block device for /dev/sda1
chmod 666 /mnt/tmp/sda1     # Makes it writable

This would enable direct disk modification, potentially corrupting filesystems or installing rootkits. The nodev option prevents creation/use of such device files.

Without nosuid, users can create or copy SUID/SGID binaries. Consider this attack vector:

cp /bin/bash /mnt/tmp/rootsh
chmod 4755 /mnt/tmp/rootsh  # Sets SUID bit

Now when executed, rootsh would run with root privileges. The nosuid mount option prevents this by ignoring SUID/SGID bits.

An attacker could combine these vulnerabilities:

1. Create SUID binary in the mounted tmpfs
2. Use it to escalate privileges
3. Create device files to modify system storage

For tmpfs mounts accessible by non-root users:

# Secure tmpfs mount in /etc/fstab
tmpfs  /mnt/tmp  tmpfs  defaults,nodev,nosuid,noexec,size=1G  0 0

For ramfs (note: ramfs doesn't respect size limits):

ramfs  /mnt/ram  ramfs  defaults,nodev,nosuid,noexec  0 0

To check active mount options:

mount | grep tmpfs
findmnt -t tmpfs -o TARGET,OPTIONS

For ongoing monitoring, consider adding these checks to your security audits:

#!/bin/bash
for mount in $(findmnt -t tmpfs,ramfs -n -o TARGET); do
    opts=$(findmnt -n -o OPTIONS --target "$mount")
    [[ "$opts" != *nodev* ]] && echo "WARNING: $mount missing nodev"
    [[ "$opts" != *nosuid* ]] && echo "WARNING: $mount missing nosuid"
done