Chapter 5: Filesystem Security and Data Protection
Chapter 5: Filesystem Security and Data Protection
Persistent storage is the primary repository of enterprise value and the ultimate objective of unauthorized intruders. If an attacker gains local access, weak filesystem mount options, unencrypted block devices, permissive access control lists, or unprotected temporary directories allow rapid data exfiltration, tampering, and privilege escalation.
This chapter establishes end-to-end data protection at rest and in transit through the Linux filesystem hierarchy. We cover defensive mount options, POSIX Access Control Lists (ACLs), Linux extended attributes, full-disk encryption with LUKS2 and TPM2 auto-unlock, secure secrets storage, temporary directory protection, removable media defense with USBGuard, and tamper-evident backup patterns.
Filesystem Security and Mount Options
Storage volumes should not be mounted with default, permissive options. The Linux VFS layer provides mount flags that neutralize common privilege escalation vectors directly at the filesystem boundary:
┌────────────────────────────────────────────────────────────────────────┐
│ DEFENSIVE MOUNT FLAGS │
│ │
│ Flag Security Guarantee │
│ ────────── ─────────────────────────────────────────────────────── │
│ nosuid Ignores SUID and SGID bits. Executables run with caller's│
│ privileges even if file has 4755 permissions. │
│ noexec Blocks execution of binary code directly from volume. │
│ nodev Prevents interpretation of character or block devices. │
│ ro Mounts filesystem as strictly read-only. │
└────────────────────────────────────────────────────────────────────────┘Partitioning Strategy and Recommended /etc/fstab Options
Separating system partitions prevents a denial-of-service attack (e.g., filling /var/log or /tmp) from crashing root (/):
# /etc/fstab hardened mount options
# Dedicated /tmp partition: no devices, no SUID binaries, no executable scripts
tmpfs /tmp tmpfs defaults,nodev,nosuid,noexec,mode=1777,size=2G 0 0
# Shared memory /dev/shm
tmpfs /dev/shm tmpfs defaults,nodev,nosuid,noexec 0 0
# /var/tmp: Bound to /tmp or mounted with identical restrictions
/tmp /var/tmp none bind,nodev,nosuid,noexec 0 0
# Dedicated /home partition: prevent users from creating device nodes or SUID root tools
UUID=1234-abcd-... /home ext4 defaults,nodev,nosuid 0 2
# Read-only boot partition (remount rw only during kernel updates)
UUID=5678-efgh-... /boot ext4 defaults,nodev,nosuid,ro 0 2Access Control Lists and Extended Attributes
Standard POSIX permissions (owner:group:others) are often too coarse for multi-tenant enterprise applications where multiple disparate services require distinct read or write access to shared datasets.
POSIX Access Control Lists (ACLs)
ACLs allow administrators to attach fine-grained permissions to files and directories for specific users and groups without altering the primary ownership:
# Grant user 'auditor' read-only access to /var/log/audit/
sudo setfacl -m u:auditor:r-x /var/log/audit/
# Grant group 'developers' read-write access to a shared directory
sudo setfacl -m g:developers:rwx /opt/project/data/
# Set default ACLs so all future files created inherit the permissions
sudo setfacl -d -m g:developers:rwx /opt/project/data/
# Inspect effective ACLs
getfacl /opt/project/data/Extended Attributes and Immutability (chattr)
Extended filesystem attributes (supported on ext4, XFS, and Btrfs) enforce controls that even root cannot bypass without explicitly removing the attribute:
- Immutable (
+i): The file cannot be modified, deleted, renamed, or linked to. Even root cannot edit an immutable file. - Append-Only (
+a): Data can only be appended to the file; existing contents cannot be truncated, overwritten, or deleted. Ideal for security log files.
# Make audit log append-only so an attacker cannot erase traces
sudo chattr +a /var/log/audit/audit.log
# Protect critical configuration file from tampering
sudo chattr +i /etc/resolv.conf
# View extended attributes
lsattr /var/log/audit/audit.log /etc/resolv.confDisk Encryption with LUKS
Data at rest must be protected against physical theft, decommissioned drive leakage, and hypervisor storage snapshot exfiltration. LUKS2 (Linux Unified Key Setup version 2) is the Linux standard for block-level encryption using dm-crypt.
┌────────────────────────────────────────────────────────────────────────┐
│ LUKS2 ENCRYPTION TOPOLOGY │
│ │
│ Filesystem Layer: ext4 / XFS (Files, directories, inodes) │
│ │ │
│ ▼ │
│ Decrypted Device Mapper: /dev/mapper/cryptroot │
│ │ │
│ ▼ AES-XTS-256 Symmetric Decryption (Hardware AES-NI) │
│ Encrypted Physical Partition: /dev/nvme0n1p3 (LUKS2 Container) │
│ │ │
│ ▼ Unlocks via: │
│ ┌───────────────────────────────────┬────────────────────────────┐ │
│ │ Key Slot 0: Passphrase / Keyfile │ Key Slot 1: TPM2 (PCR 0+7) │ │
│ └───────────────────────────────────┴────────────────────────────┘ │
└────────────────────────────────────────────────────────────────────────┘Formatting and Opening a LUKS2 Volume
# Format volume with AES-XTS-256 and Argon2id key derivation
sudo cryptsetup luksFormat --type luks2 --cipher aes-xts-plain64 --key-size 512 --hash sha512 /dev/nvme0n1p3
# Open encrypted volume and map to decrypted device
sudo cryptsetup open /dev/nvme0n1p3 cryptroot
# Create filesystem on decrypted device
sudo mkfs.ext4 /dev/mapper/cryptrootTPM2 Hardware Binding with systemd-cryptenroll
To enable secure, headless boot without embedding plaintext keys on disk, bind the LUKS2 volume to the system’s TPM 2.0 chip, sealed to Platform Configuration Registers (PCRs) 0 (firmware) and 7 (Secure Boot state):
# Enroll TPM 2.0 with PCR 0 and 7 measurements
sudo systemd-cryptenroll --tpm2-device=auto --tpm2-pcrs=0+7 /dev/nvme0n1p3
# Update /etc/crypttab for automatic boot unlocking
# cryptroot UUID=... none tpm2-device=autoIf the firmware is modified or Secure Boot is tampered with, the TPM refuses to release the decryption key, preventing the machine from booting.
Secrets and Configuration File Protection
API keys, database credentials, TLS private keys, and environment tokens must be handled with extreme care:
Strict File Permissions: Secrets files must be owned by the target service user with mode
0400or0600:sudo chown myapp:myapp /etc/myapp/secrets.env sudo chmod 0400 /etc/myapp/secrets.envVolatile Memory Storage (
tmpfs): Store runtime decryption keys in memory-backed filesystems (tmpfs) rather than writing them to persistent disks, ensuring they disappear upon system power-off:sudo mount -t tmpfs -o size=64M,mode=0700,nodev,nosuid,noexec tmpfs /run/secrets/Linux Kernel Keyrings: Utilize the kernel keyring facility (
keyctl) to store cryptographic keys inside kernel memory rather than exposing them in process environment variables (/proc/$PID/environ), which are readable by other processes sharing the UID.
Temporary Files and Sensitive Data Handling
The /tmp and /var/tmp directories have historically been fertile ground for symlink attacks, race conditions, and temporary data leakage.
Kernel Hardlink and Symlink Restrictions
Modern Linux kernels include protection against symlink and hardlink spoofing attacks where an attacker tricks a root process into overwriting arbitrary system files:
# /etc/sysctl.d/99-filesystem-security.conf
fs.protected_symlinks = 1
fs.protected_hardlinks = 1
fs.protected_fifos = 2
fs.protected_regular = 2fs.protected_symlinks = 1: Disallows following symlinks in world-writable sticky directories unless the owner of the symlink matches the owner of the target file or the directory.fs.protected_hardlinks = 1: Disallows creating hardlinks to files the user does not personally own or have write access to.
Removable Media Security
Plugging an unauthorized USB storage device into a physical server presents immediate risks: BadUSB firmware spoofing, malicious HID keyboard injections, and data exfiltration.
Disabling USB Storage via Kernel Module Blacklist
# Blacklist usb-storage driver
cat << 'EOF' | sudo tee /etc/modprobe.d/disable-usb-storage.conf
blacklist usb-storage
install usb-storage /bin/true
EOFSecure Backup and Recovery
A hardening strategy without verifiable backups is incomplete:
- Immutable Offsite Storage: Backups must be replicated to immutable, append-only destinations (such as S3 object locks or air-gapped repositories) where even a root compromise on the production server cannot delete historic snapshots.
- Client-Side Encryption: Backups must be encrypted before leaving the host using modern tools like Restic or BorgBackup with authenticated encryption (AES-256-GCM or ChaCha20-Poly1305).
- Automated Restore Drills: Backups must be tested quarterly through automated spin-up rehearsals. Untested backups are not backups.