Mount options & filesystem

noexec, nosuid, nodev where they belong.

How filesystems are mounted is a quietly powerful hardening lever. Mount options can strip capabilities from whole directories: noexec forbids executing any binary from that filesystem, nosuid ignores SUID/SGID bits there, and nodev ignores device files. Applied to the right places — especially world-writable ones like /tmp — they neutralize entire attack techniques regardless of file permissions, because the restriction is on the mount, not the individual file.

# separate partitions (or bind mounts) with restrictive options
/dev/sdb1  /tmp       ext4  defaults,nodev,nosuid,noexec  0 2
/dev/sdb2  /var       ext4  defaults,nodev,nosuid          0 2
tmpfs      /dev/shm   tmpfs defaults,nodev,nosuid,noexec  0 0
# /home often gets nodev,nosuid too

Why noexec on /tmp matters so much

Recall from the essentials course that /tmp is world-writable — anyone, including a compromised low-privilege process, can write there. Mounting /tmp with noexec means that even though an attacker can drop a binary or script-payload into /tmp, they cannot run it directly from there, which breaks a very common post-exploitation step. Combined with nosuid (so a dropped SUID binary is ignored) and nodev (so a fake device file is inert), these three options turn /tmp from a launchpad into a dead end for a lot of tooling.

Separation and read-only where possible

Two structural habits reinforce this. Putting /tmp, /var, /var/log, and /home on their own partitions means one filling up (or being flooded by an attacker) does not take down the whole system, and lets each carry its own mount options. And mounting truly static areas read-only where the workload allows prevents tampering with system binaries at all. The goal is that each part of the filesystem has exactly the capabilities it needs and no more — the mount-level version of least privilege.

$ mount | grep -E "/tmp|/var|/home"      # verify the options actually applied
/dev/sdb1 on /tmp type ext4 (rw,nosuid,nodev,noexec,...)
$ findmnt --verify                        # sanity-check fstab before a reboot strands you