In this lesson, you will learn how to leverage kernel features to render your host environment immutable, ensuring that even if a container is compromised, the attacker cannot persist their presence.
The Philosophy of Ephemeral Hosts
In a standard Linux setup, an attacker who gains root access within a container might attempt to modify host binaries, insert malicious kernel modules, or alter system configurations to maintain a foothold. "System State Immutability" treats the host's operating system as a read-only artifact. By enforcing this state at the kernel level, we ensure that any unauthorized modification attempt is rejected, regardless of the attacker's elevated privileges inside a container.
Enforcing Immutability
To achieve true immutability, we combine Kernel Lockdown Mode with read-only root filesystems. When the kernel is in integrity or confidentiality lockdown mode, it prevents even root users from modifying kernel memory or loading unsigned modules, effectively killing the "persistence" phase of a typical container exploit.
Beyond the kernel, you should enforce immutability on the filesystem level. By mounting your system partitions as ro (read-only) and using dm-verity to ensure the integrity of the underlying block device, you prevent an attacker from overwriting binaries like /usr/bin/python or shell utilities that are frequently used in post-exploitation.
For example, to prevent changes to the root filesystem even by the host's superuser, you can remount the partition:
# Remount the root partition as read-only
mount -o remount,ro /
# Optionally, use chattr to prevent attribute changes on critical files
# even if the mount wasn't strictly read-only
chattr +i /etc/passwd /etc/shadow
Preventing Persistence
The primary defense against container-to-host persistence is denying the container the ability to interact with the host's mutable state. By combining Kernel Lockdown Mode to protect the kernel interface and Read-Only Root Filesystems to protect the disk, you create a "stateless" environment. If an intruder attempts to write a persistence script to /usr/local/bin or load a rootkit, the kernel simply denies the write request. The system state remains exactly as it was when the machine booted, effectively "self-healing" upon the container's destruction.
Key Takeaway: By enforcing Kernel Lockdown Mode and read-only filesystems, you neutralize an attacker's ability to achieve persistence, forcing the host to remain in a pristine, known-good state regardless of container-level breaches.