Linux Mount Security: fstab, nosuid, nodev, noexec, and Filesystem Boundaries

1. Introduction

Mount options define more than where a filesystem appears. They can determine whether executables run, whether device files are honored, whether SUID bits are effective, and whether data is writable. Thoughtful mount policy is therefore a practical way to reduce the impact of compromised user-writable locations. This article focuses on defensive administration, auditing, and authorized lab work. The objective is to understand the control, identify misconfiguration before it becomes an incident, and build a repeatable hardening process that can be applied across real Linux environments.

2. How It Works

Linux mounts filesystems into a single directory tree. /etc/fstab defines persistent mounts, while systemd may translate entries into mount units. Security-related options include nosuid, nodev, noexec, ro, and options specific to individual filesystems. Linux security is layered, so this control should be considered together with identity, filesystem permissions, service configuration, kernel policy, network segmentation, and centralized monitoring. A single command rarely tells the whole story; the effective security posture comes from how these layers interact.

3. The Security Problem

A user-writable filesystem that permits SUID execution or device nodes may expand attack surface. Temporary filesystems, removable media, shared application storage, and container-related mounts require special attention. At the same time, noexec is not a complete security boundary because interpreters may still read scripts. These weaknesses are often created gradually by troubleshooting, legacy migrations, vendor installation scripts, or temporary exceptions that later become permanent. A good security review therefore looks not only for obviously dangerous settings, but also for configuration that no longer has a clear owner or business justification.

4. How Attackers Abuse It

Attackers benefit from writable locations where privileged execution semantics remain available. They may also hide tools or data on unusual mounts. Defenders use mount options to reduce available primitives and to understand where persistence or data staging can occur. In an authorized assessment, the goal is to demonstrate exposure safely and report the exact condition that creates the risk. In production incident response, avoid making destructive changes before collecting enough context to understand whether the issue is a simple misconfiguration, active abuse, or a persistence mechanism.

5. How to Detect / Enumerate & Audit It

Command

findmnt -o TARGET,SOURCE,FSTYPE,OPTIONS

What it does: Show mounted filesystems and options.

What to look for: User-writable mounts lacking nosuid/nodev where those options make sense.

Defensive use: Create a mount-security inventory.

Command

cat /etc/fstab

What it does: Display persistent filesystem configuration.

What to look for: Broad rw mounts, weak temporary filesystem settings, or unexpected network shares.

Defensive use: Review boot-time mount policy.

Command

findmnt /tmp /var/tmp /home 2>/dev/null

What it does: Inspect common writable locations.

What to look for: Whether separate mounts and security flags are applied.

Defensive use: Focus review on high-risk paths.

Command

mount | grep -E ' /tmp | /var/tmp | /home '

What it does: Quick alternative view of selected mounts.

What to look for: Missing security options.

Defensive use: Validate runtime state.

A useful operational habit is to save the output of these checks in a baseline for each server role. A database server, bastion host, developer workstation, and container node will not look identical, so comparison should be against a known-good peer or documented configuration rather than against a generic assumption.

6. How to Audit the Environment

• Classify filesystems by purpose: system, application, user data, temporary, removable, or network.
• Apply nosuid and nodev to user-writable filesystems where compatible.
• Use noexec as defense in depth where applications do not require direct execution.
• Review NFS and other network mounts for trust and credential exposure.
• Confirm runtime mounts match /etc/fstab and intended systemd units.
• Document every exception with an owner, reason, and review date.
• Re-check the control after upgrades because packages and deployment automation can silently change defaults.

7. How to Fix / Harden It

• Separate high-risk writable areas onto dedicated filesystems when operationally practical.
• Add appropriate mount flags and test applications before rollout.
• Use read-only mounts for static data where possible.
• Remove stale network shares.
• Protect /etc/fstab and mount units with configuration monitoring.
• Apply changes through configuration management when possible so the desired state is reproducible.
• Test hardening first on a staging host or a disposable snapshot and verify that critical services still function.

8. Detection & Monitoring

• Alert on new mounts, especially removable or network filesystems.
• Track changes to /etc/fstab and systemd mount units.
• Investigate unexpected writable mounts introduced during incidents.
• Keep time synchronization reliable so host events can be correlated with firewall, identity, EDR, and SIEM data.
• Send high-value security logs off-host because a fully compromised root account can often alter local evidence.

9. MITRE ATT&CK Mapping

MITRE ATT&CK is most useful here as a common language for detection engineering and incident reporting. The mapping does not mean every misconfiguration is an active attack; it shows which attacker behaviors may become easier when the control is weak.

10. Practical Lab

In an isolated Linux lab or disposable VM:

1. Create a loopback filesystem in a VM.
2. Mount it with and without nosuid, nodev, and noexec.
3. Observe how behavior changes.
4. Add a temporary fstab entry and verify with findmnt.
5. Remove the lab mount cleanly.
6. Capture screenshots or command output before and after the change so you can prove what the control actually changed.
7. Revert the VM or remove the test configuration when finished.

11. Key Takeaways

• Linux Mount Security should be treated as part of a layered security model, not as an isolated setting.
• Inventory the current state first, because unknown configuration is difficult to secure.
• Prefer least privilege, explicit ownership, and documented exceptions.
• Monitor changes to the control itself; attackers often try to weaken defenses after gaining access.
• Test fixes in a lab and verify the effective runtime state, not only the configuration file.

Continue learning: Linux Security

This guide is part of our Linux Security series. Related guides in this series cover permissions, sudo, SUID/SGID, Linux capabilities, SSH, PAM, systemd, logging, firewalls, DNS, process security, filesystems, encryption, auditd, kernel hardening, containers, mandatory access control, package security, incident response, and backup protection.