# CL-0017: Shared Mount Propagation

**Severity:** MEDIUM

**References:**
- CIS Docker Benchmark 5.20 — Ensure mount propagation mode is not set to shared

## What it detects

Services using shared mount propagation in either syntax:
- Short syntax: `:shared` suffix (e.g., `/data:/app/data:shared`)
- Long syntax: `bind.propagation: shared`

Other propagation modes (`rprivate`, `rslave`, etc.) and mounts without explicit propagation are not flagged.

## Why it matters

Shared mount propagation means mounts created inside the container are visible on the host, and mounts created on the host are visible inside the container. This breaks mount namespace isolation and can be exploited to:
- Mount arbitrary filesystems that become visible on the host
- Access newly mounted host filesystems that were not present when the container started
- Escape container confinement by creating strategic mount points

## Fix

Remove `:shared` or change the propagation to `rprivate` (the Docker default):

```yaml
# Before — short syntax
services:
  app:
    image: myapp:1.0
    volumes:
      - /data:/app/data:shared

# After
services:
  app:
    image: myapp:1.0
    volumes:
      - /data:/app/data

# Before — long syntax
services:
  app:
    image: myapp:1.0
    volumes:
      - type: bind
        source: /data
        target: /app/data
        bind:
          propagation: shared

# After
services:
  app:
    image: myapp:1.0
    volumes:
      - type: bind
        source: /data
        target: /app/data
        bind:
          propagation: rprivate
```

If your workload requires mount visibility between host and container (e.g., CSI drivers), use `rslave` instead of `shared` — it allows host-to-container propagation without the reverse.

`rslave` is a partial fix, not a clean one: a malicious or compromised host process can still inject mounts into the container at sensitive in-container paths, which the workload may then read or execute from. If the only reason you reach for `shared`/`rslave` is symmetric debugging, consider whether the bind mount needs propagation at all (`rprivate` is almost always correct).

## When to suppress

- CSI / Kubernetes node plugins that genuinely require bidirectional propagation to operate.
- Specific Docker-in-Docker setups where the inner daemon's bind mounts need to be visible on the host. Suppress with a `reason:` naming the workload; never suppress globally.

## See also

- [CL-0013](CL-0013.md) — sensitive host paths (the surface a shared propagation can newly expose)
