Read-Only Filesystems and no-new-privileges

A default container has a writable layer (Chapter 6), so a process that lands inside can drop a binary, rewrite a config, or persist a backdoor that survives a restart. Running with --read-only makes the root filesystem immutable and forces you to declare exactly which directories actually need to be writable, mounting those as tmpfs. Paired with --security-opt no-new-privileges, which blocks setuid escalation, driftwood/web becomes a process that can neither modify itself nor gain privileges it didn't start with.

These two flags close the last common in-container paths. The read-only rootfs stops persistence and tampering; no-new-privileges stops a non-root process from climbing back up through a setuid binary. Together with the non-root user, the dropped capabilities, and the seccomp and LSM profiles from the earlier topics, a compromise inside driftwood/web has nowhere to write, nothing to escalate, and very little it can do.

The Writable Layer Is the Problem

Every container gets a thin read-write layer stacked over the read-only image layers (Chapter 6). That layer is convenient — it is where an app writes temp files and logs — and it is also where an attacker writes. Malware persists by dropping a file there; a tampered binary survives because the write sticks for the life of the container. Immutability removes that surface: if the layer can't be written, none of it can happen.

--read-only Forces Immutability

The --read-only flag mounts the entire root filesystem read-only, so the application code and the OS files inside the image cannot be altered at run time. The container can read its image but not rewrite it. A useful side effect is that the flag surfaces every place the app secretly expected to write — the moment it tries, you get an error, and now you know about a write path you didn't know existed.

tmpfs for Writable Scratch

Apps still need some writable paths — /tmp, a cache directory, a pid file. The answer is not to drop --read-only but to declare those paths explicitly with --tmpfs (or --mount type=tmpfs), which gives each one an in-memory, ephemeral filesystem that vanishes when the container stops. Writes are allowed exactly where you declared them and nowhere durable, so the app works while the rootfs stays immutable.

docker run -d --name web \
  --user app \
  --cap-drop=ALL \
  --read-only \
  --tmpfs /tmp \
  --security-opt no-new-privileges \
  -p 8000:8000 \
  driftwood/web

This is the accumulated hardening so far on one line: the non-root app user from topic 60, the dropped capabilities from topic 61, the read-only rootfs with a tmpfs for /tmp, and no-new-privileges. A process that lands inside has no root, no capabilities, no writable rootfs, and no way to escalate.

no-new-privileges Stops setuid Escalation

--security-opt no-new-privileges sets the kernel flag that prevents a process from gaining privileges through setuid or setgid binaries. Even if a setuid-root binary exists somewhere in the image — sudo, ping, or one that slipped in with a base image — it cannot be used to escalate. That closes a classic in-container privilege-escalation path: a compromised non-root process finds a setuid-root binary and rides it up to root. With the flag set, the ride goes nowhere.

Driftwood, Hardened

Stack everything this chapter has added and driftwood/web runs --read-only with a tmpfs for /tmp, --security-opt no-new-privileges, as the non-root app user, with --cap-drop=ALL. A process that compromises the app has no root, no capabilities, no writable root filesystem, and no path to escalate. It is not invulnerable — it can still abuse the network or try to read data the app legitimately reads — but the easy wins are gone.

A read-only rootfs is one layer, not the whole answer. It stops persistence and tampering; it does not stop a process from exfiltrating data over a connection the app is allowed to make, and it does not protect a writable volume mounted into the container. Treat it as one more independent control in the defense-in-depth stack, valuable precisely because it does not depend on the others holding.