Podman Rootless Containers and the Copy Fail Exploit: Analyzing the Blast Radius
The disclosure of CVE-2026-31431, known as "Copy Fail," has sent ripples through the Linux community. This vulnerability allows a local unprivileged user to obtain a root shell by exploiting the way the kernel handles certain file operations, effectively allowing a user to overwrite files they should only have read-only access to.
For those utilizing containerization, the implications are significant. Containers are often used to isolate public-facing services, CI/CD jobs, and development environments. If an attacker gains a foothold via Remote Code Execution (RCE), Copy Fail could potentially be used to escalate privileges within the container. This article examines the vulnerability specifically within the context of Podman's rootless containers and explores how different configurations impact the "blast radius" of such an attack.
Understanding Rootless Containers
To understand the impact of Copy Fail, it is first necessary to understand how Podman implements rootless containers. Unlike the traditional Docker daemon model—where a rootful daemon spawns containers—Podman uses a fork/exec model. The container process is a direct descendant of the podman run process, meaning it inherits the UID of the user who started it.
User Namespaces and UID Mapping
Podman leverages Linux user namespaces to provide isolation. This allows a process to have one UID inside the container and a different one on the host. For example, a process running as root (UID 0) inside a rootless container is mapped to the unprivileged user (e.g., UID 1001) on the host.
This mapping is governed by /etc/subuid, which defines a range of UIDs that the unprivileged user can allocate to namespaced processes. This ensures that even if a process is root inside the container, it remains an unprivileged user from the host's perspective, severely limiting its ability to damage the host system.
Linux Capabilities
Root privileges in Linux are not monolithic; they are broken down into "capabilities." Podman uses these to grant granular permissions to container processes. For instance, installing packages via apt requires capabilities like CAP_CHOWN and CAP_SETUID.
By default, a rootless rootful container (running as root inside the namespace) is granted a wide array of capabilities. This creates a larger attack surface. A more secure approach is to run a "rootless non-root" container, where the process runs as an unprivileged user both inside and outside the container, with all unnecessary capabilities dropped.
Testing the Copy Fail Exploit
In practical tests, Copy Fail was used to attempt privilege escalation within various Podman configurations. The exploit typically involves downloading a Python script that allows the su command to be executed without a password prompt, granting a root shell.
Rootless Rootful Containers
In a configuration where the process is already running as root inside the container, Copy Fail is redundant. The user already has the privileges the exploit seeks to provide. However, the process remains mapped to an unprivileged user on the host, meaning the host's root files remain inaccessible.
Rootless Non-Root Containers
This is where the exploit becomes potent. In a container running as an unprivileged user (e.g., foo), Copy Fail successfully escalates the process to container root.
While the attacker now has root privileges inside the container and can access files owned by the namespace root, they are still limited by the host user's permissions. They cannot access files owned by the host's actual root user.
Mitigating the Escalation
Two primary Podman flags can be used to impede the immediate effect of the Copy Fail exploit:
--security-opt=no-new-privileges: This prevents a process from gaining additional privileges. When this flag is set, the Copy Fail exploit fails to yield a root shell; the user remainsfoo.--cap-drop=all: Dropping all capabilities similarly prevents the exploit from successfully escalating to a privileged root shell.
It is important to note that while these flags prevent the su exploit, the underlying vulnerability—the ability to overwrite read-only files in the page cache—still exists. The kernel must be patched to fully resolve the issue.
Defense in Depth: Limiting the Blast Radius
Since no single security boundary is foolproof, a defense-in-depth strategy is essential to limit the damage a compromised container can do.
Read-Only Filesystems
Using the --read-only flag (combined with --read-only-tmpfs=false) mounts the container's root filesystem as read-only. This prevents an attacker from writing malicious binaries or modifying system configurations post-exploit, although it does not stop the exploit from running in memory via piped commands.
Resource Constraints
Utilizing cgroups to limit memory, CPU, and PID counts ensures that a compromised container cannot be used to launch a Denial of Service (DoS) attack against the host or other containers.
Minimal Images
Reducing the available toolset for an attacker is a critical step. Using ubuntu as a base image provides a wealth of binaries (like curl and python3) that facilitate exploits. Moving toward -slim images, Alpine Linux, or "distroless" images removes shells and package managers, making it significantly harder for an attacker to bootstrap an exploit.
Network Firewalling
Restricting incoming and outgoing connections via iptables or nftables prevents a compromised container from communicating with a Command and Control (C2) server or performing lateral movement within the internal network.
Critical Perspectives and Counterpoints
While the primary exploit example focuses on gaining a root shell via su, community discussion highlights that the true danger of Copy Fail is broader.
"This vulnerability makes all sorts of stuff that were supposed to be shared read-only with the container actually sorta writable, so the blast radius is going to be enormous in many contexts, even when not as universally trivially exploitable as with the 'su' example."
Furthermore, some researchers point out that Copy Fail could be used for lateral attacks between containers. If two containers share a base image layer, a malicious container could potentially overwrite a file in that shared layer to compromise a second container running under the same unprivileged user.
There is also a growing sentiment that the Linux kernel's isolation mechanisms (namespaces, seccomp) may be insufficient for high-security environments, leading some to advocate for MicroVMs as a stronger security boundary.
Conclusion
Podman's rootless architecture provides a significantly better security posture than standard rootful Docker installations by ensuring that container root is never host root. However, as Copy Fail demonstrates, containers are not an impenetrable wall. By combining rootless execution with dropped capabilities, no-new-privileges options, and minimal images, administrators can drastically reduce the blast radius of a compromise. Ultimately, the most effective defense remains a combination of timely kernel patching and a layered security approach that assumes the container boundary will eventually be breached.