CL-0010: Host PID and IPC namespace sharing¶

Severity: HIGH

Derivation (see severity model):

Baseline: A — the attacker already has code execution in this container, as the workload uid
Precondition: Technique — the host process table and IPC objects become visible immediately, but converting that visibility into impact takes a technique: signalling a host process, or reading and writing a shared memory segment another workload trusts
Impact: Cross-container — every container's processes and IPC objects, plus the host's
Qualifier/modifier: none
Derived: Technique × Cross-container = HIGH
Shipped: HIGH
Evidence: _cl0010 — under pid: host a container saw 291 host processes on a live daemon. The reach is visibility and signalling: reading /proc/1/environ at default capabilities is denied (verified), so the secret-disclosure path belongs to SYS_PTRACE and an unconfined AppArmor profile, which other rules score

References: - OWASP Docker Security Rule #3 - CIS Docker Benchmark 5.16 — Ensure that the host's process namespace is not shared - CIS Docker Benchmark 5.17 — Ensure that the host's IPC namespace is not shared

What it detects¶

Any service with: - pid: host — shares the host's PID namespace - ipc: host — shares the host's IPC namespace

Other values (e.g., ipc: shareable) are not flagged.

uts: host and userns_mode: host used to be flagged here and are not any more. Both are no-ops under the posture these rules are graded against (ADR-020):

uts: host shares the host's UTS namespace, but changing the hostname needs CAP_SYS_ADMIN, which is not in Docker's default set. Verified: the call is refused (sethostname: Operation not permitted) even when setting the hostname to the value it already had. The container reads the host's hostname and cannot change it.
userns_mode: host opts out of daemon-level UID remapping, which only exists when the daemon runs with --userns-remap. Against a daemon at defaults there is nothing to opt out of — /proc/self/uid_map is identical with and without it.

Flagging a directive that changes nothing is what removed CL-0023, and the same bar applies here. If you run with --userns-remap, userns_mode: host is meaningful on your hosts — that is a departure from the documented posture, and the honest place to catch it is a policy check that knows your daemon configuration.

Why it matters¶

Linux namespaces are a core container isolation mechanism. Sharing them with the host removes that boundary:

`pid: host`¶

The container sees every process on the host and can signal them, including SIGKILL — verified live: a default-capability container under pid: host listed 291 host processes. That is a recon and denial-of-service primitive against the host and every other container on it, and it defeats the PID-namespace boundary that makes a container's process list its own.

Reading another process's environment via /proc/[pid]/environ is not part of what this directive grants. An earlier revision of this page claimed it was; at default capabilities the read is refused (Permission denied, verified on /proc/1/environ). Getting it requires SYS_PTRACE and an unconfined AppArmor profile — two separate configurations, flagged by CL-0011 and CL-0009. Scoring that disclosure here would be claiming two other rules' impact as this one's.

`ipc: host`¶

The container can attach to host shared memory segments, potentially reading sensitive data from other applications or injecting data into them.

Fix¶

Remove the namespace sharing directive:

# Before
services:
  monitor:
    image: myapp:1.0
    pid: host
    ipc: host

# After
services:
  monitor:
    image: myapp:1.0

If your application requires cross-container PID visibility (e.g., sidecar patterns), use pid: "service:other-container" instead of pid: host to limit the scope.

Out of scope¶

Compose also accepts cgroup: host (cgroup-namespace sharing). This rule does not currently flag it — CIS does not benchmark it specifically and the threat model is narrower than the four namespaces above. It is still a hardening regression and may be covered in a future rule.

ATT&CK coverage¶

Remediating this finding contributes to mitigating the following MITRE ATT&CK techniques (pinned to ATT&CK v18). compose-lint is a static analyser, so this is mitigation coverage — it detects nothing at runtime.

Technique	Tactic
T1611 Escape to Host	Privilege Escalation