Read-Only Filesystem

Why a Read-Only Filesystem Matters

A read-only filesystem makes the runtime environment harder to modify after an attacker gets code execution. That matters because many post-compromise actions, including planting persistence, tampering with binaries, or dropping tools, depend on writable paths. It is most effective when paired with separate writable mounts for logs, caches, uploads, and application state.

In containerised workloads, this control helps shift the default from “the process can write anywhere it can reach” to “the process can only write where the platform explicitly allows it.” That reduces the blast radius of a compromised container and makes unexpected writes easier to spot.

What a Read-Only Filesystem Does and Does Not Do

The control protects the container’s runtime filesystem, not the entire workload. A process may still write to mounted volumes, network storage, tmpfs locations, or external services if those paths remain writable. In practice, a secure design separates immutable application code from mutable runtime data so the application can function without needing broad write access.

That distinction is important because the setting is often misunderstood as a complete hardening measure. It is better viewed as one boundary in a larger containment model, where file permissions, mount options, privilege reduction, and image hygiene all work together.

How It Limits Post-Compromise Abuse

When attackers can alter the runtime filesystem, they may replace executables, modify startup scripts, install web shells, or leave behind tooling for later access. A read-only filesystem interrupts those paths by making the container root filesystem immutable during normal execution. It can also frustrate some data collection and destructive actions that rely on writing to local disk.

The control is not a guarantee against compromise, because an attacker may still operate in memory, use existing writable mounts, or abuse application logic and network reach. But it does narrow the set of easy persistence and tampering options, which makes both intrusion and recovery harder for the attacker.

Where It Fits in Container Hardening

Read-only filesystems are most valuable when the application has been designed for immutability from the start. That means the image contains only what is needed to run, while anything that must change at runtime is redirected to a controlled writable location. This pattern is common in hardened container builds and aligns with broader least-privilege design.

It is also a practical test of application design quality. If a service breaks when the root filesystem is made read-only, that usually reveals hidden assumptions about where it writes state, and those assumptions should be made explicit rather than left to the default filesystem layout. Embedded Linux and Yocto Hardening Guide covers the same immutable-root approach in embedded builds, where read-only root filesystems are a common hardening pattern.

Risk and Threat Considerations

A read-only filesystem reduces the ease of post-exploitation tampering, but it does not eliminate compromise. The main residual risk is that attackers can still abuse any writable mount, memory-resident payload, exposed secrets, or external control channel, so the control should be treated as containment rather than prevention.

Failure mechanism: If the container still has writable mounts or overly broad runtime permissions, an attacker can bypass the read-only root by writing to those alternate paths and continue persistence or sabotage.

Impact: The environment may still be altered after compromise, but the attack becomes more constrained, easier to detect, and less likely to persist silently across restarts.

Practitioner Guidance

Why practitioners should care: Make the filesystem decision part of the container contract, not an afterthought. If the application expects writes, define exactly which directories need them and keep everything else immutable.

What to watch for: Common breakpoints include unexpected log writes, temporary file creation, package managers, runtime caches, and libraries that assume they can modify their own installation path.

Practitioner takeaway: A read-only filesystem works best when the application is deliberately built to be stateless at runtime, with all legitimate write paths isolated and reviewed.

Related resources from NHI Mgmt Group

• Why should Kubernetes containers use a read-only root filesystem?
• What breaks when a coding agent can read the host filesystem directly?
• Filesystem Read Primitive
• Why do read-only AI agents still create serious security risk?