Overview

Most security effort goes into keeping attackers out. Filesystem security is about what happens once someone (or something) already has a foothold, or once a disk leaves your control. It assumes the perimeter can fail and asks three quieter questions: what can a filesystem be used for, who can read the bytes if the hardware is stolen, and would you even notice if a file changed underneath you. Each question maps to one technique, and the three compose into defence in depth for data at rest.

The three layers

These layers are independent. You can apply any one without the others, but they cover different threats, so a hardened host usually wants all three.

Layer	Threat addressed	Primary tool	When it helps
Mount options	Abuse of writable areas (dropped binaries, device nodes, setuid escalation)	/etc/fstab flags: nodev, nosuid, noexec, ro	Attacker already has some access and wants to run or escalate
Disk encryption	Physical theft, decommissioned or resold disks	LUKS via cryptsetup	Hardware or a drive leaves your physical control
Integrity monitoring	Persistence and tampering after a breach	AIDE, dpkg --verify	Detecting change you did not authorise

Reducing what a filesystem allows

A filesystem does not have to permit everything everywhere. A world-writable scratch area like /tmp has no legitimate need to hold device nodes, run setuid programs, or execute binaries. Mount options let you strip those capabilities per mount point, so that even if an attacker drops a payload into /tmp, the kernel refuses to execute it. This is cheap, reversible, and costs nothing at runtime. See Mount Options for the specific flags and sensible defaults for /tmp, /home, and removable media.

Encrypting disks and volumes

Mount options mean nothing if the attacker simply removes the drive and reads it on another machine. Encryption at rest defends against that: without the key, the bytes are noise. On Linux the standard is LUKS, which encrypts a whole block device and manages up to eight key slots (passphrases or key files). Encryption protects data when the machine is powered off or the disk is detached. It does not protect a running system where the volume is already unlocked. See Disk Encryption for LUKS setup, key management, and the exact threat boundary.

Detecting unexpected change

Prevention is never perfect, so the third layer is detection. If an attacker replaces /bin/ls or edits /etc/passwd, you want to know. Integrity monitoring records a cryptographic baseline of chosen files and compares against it on a schedule, flagging additions, deletions, and content or permission changes. On Debian and Ubuntu the package database gives you a free first pass with dpkg --verify, and AIDE provides a richer, configurable baseline. The hard part is not the tooling but tuning it so alerts stay meaningful. See Integrity Monitoring for baselining and alert-fatigue tradeoffs.

A quick state check

Before diving into any single layer, it helps to see where a host stands. A few commands summarise all three concerns at once.

# Layer 1: which mounts already carry hardening flags?
findmnt -o TARGET,OPTIONS | grep -E 'noexec|nosuid|nodev'
# Layer 2: are any block devices LUKS-encrypted?
lsblk -o NAME,FSTYPE,MOUNTPOINT | grep -i crypt
# Layer 3: does the package database report any modified files?
sudo dpkg --verify | head

Expected output:

/tmp        rw,nosuid,nodev,noexec
sda3_crypt  crypto_LUKS
(no output from dpkg --verify means no modified packaged files)

An empty result on any line is a to-do item: unhardened mounts, an unencrypted disk, or (in the case of dpkg --verify) a clean bill of health. Each of the sibling pages picks up one of these lines in depth.

Practical Guidance

1. Treat the three layers as complementary, not alternatives: mount options limit abuse, encryption protects powered-off data, and integrity monitoring catches what slips through.
2. Start with mount options because they are the lowest-risk, zero-cost change, then layer encryption and monitoring on top.
3. Encrypt any disk that might leave your control, including laptops and any drive you plan to decommission or resell.
4. Baseline integrity as early as possible, ideally right after a clean install, so the baseline reflects a trusted state.
5. Test every change on a disposable VM with a snapshot to roll back to, since a bad fstab line or encryption mistake can leave a host unbootable.