CASE 28CONTAINERS & KUBERNETES

Container Isolation: Namespaces

A Docker container shared the host's PID namespace, letting processes inside it see and interact with host processes. I confirmed the namespace boundary was weakened and traced the path to host-level access through nsenter.

DOMAIN: Containers & Kubernetes
PLATFORM: Docker, Linux namespaces
SEVERITY: Critical
OUTCOME: Namespace escape path confirmed

TOOLS

DockerLinuxLinux NamespacesBashpsreadlinknsenter/procLinux Process ManagementContainer Runtime

RESULT

BEFORE~~Shared PID namespace~~

AFTEREscape path documented

Objective

I set out to assess whether a Docker container's Linux namespace isolation was properly configured, and whether a weakened boundary could allow a container process to interact with host processes and escape the container.

Scenario

A Docker container was running with access to the host's PID namespace, meaning processes inside the container could see host-level processes. I wanted to determine whether this shared namespace could be exploited to cross the container isolation boundary and access the host filesystem.

What I found

FINDING 01 (CRITICAL): CONTAINER COULD SEE HOST PROCESSES

The container's process list included the host's PID 1 (systemd), confirming the PID namespace was shared. The container's mount and network namespaces had different identifiers from the host's, but the shared PID namespace gave visibility into the host's process tree.

namespace-comparisonSHARED PID

Host PID 1:               /sbin/init (systemd)
Visible from container:   Yes
Container mount ns:       mnt:[<REDACTED>]
Host mount ns:            mnt:[<REDACTED>]

FINDING 02 (CRITICAL): NSENTER ALLOWED HOST NAMESPACE ACCESS

With visibility of the host's PID 1, the container could use nsenter to enter the host's mount, UTS, IPC, and network namespaces. This gave full access to the host filesystem and process tree.

namespace-escapeHOST ACCESS

Target PID:          1 (host systemd)
Namespaces entered:  mount, UTS, IPC, network
Host filesystem:     Fully accessible
Host hostname:       Confirmed different from container

What I did

Compared process trees
I listed processes inside the container and confirmed host PID 1 was visible.
Compared namespace identifiers
I used /proc to compare namespace IDs between PID 1 and the container process, confirming the PID namespace was shared.
Tested namespace entry
I used nsenter targeting PID 1 to enter the host's mount, UTS, IPC, and network namespaces.
Confirmed host access
The hostname, process list, and filesystem all matched the host, not the container.

EVIDENCE

TEXT

# Namespace isolation assessment
Container PID list:     Includes host PID 1 (systemd)
Namespace comparison:   Different mount/network ns, shared PID ns
nsenter target:         PID 1 (mount, UTS, IPC, network)
Result:                 Host filesystem and processes accessible

Validation

After entering the host namespaces, the hostname matched the host, the process list showed all host processes, and the host filesystem was accessible. The container escape through namespace weakening was confirmed.

Before and after

CONTROL	BEFORE	AFTER
PID namespace	Shared with host	Escape documented; isolation recommended
Host process visibility	Container sees host PID 1	Recommended: separate PID namespace
nsenter access	Available to container	Recommended: restrict with seccomp/AppArmor
Namespace isolation	Weakened	Recommended: full namespace separation

“Linux namespaces are a fundamental part of Docker isolation, and weakening those boundaries can allow a container process to interact with the host and ultimately escape the container security boundary.”

SKILLS IT PROVES

Container Security
Docker Security
Linux Security
Linux Namespace Isolation
Container Escape
Privilege Escalation
Vulnerability Assessment
Security Misconfiguration Analysis
Host Isolation
Container Runtime Security
Access Control
Privilege Management

View my labs on GitHub