Privilege Escalation via Docker / Container Escapes

Privilege Escalation via Docker / Container Escapes (Conceptual Overview)

Containers (Docker, LXC, Podman) provide operating-system-level virtualization. They share the host kernel but isolate processes, filesystems, and networks. Container escape occurs when a process breaks this isolation boundary and gains access to the host operating system.

🐳 What Is Container Escape?

🧠 How Container Escapes Happen (High-Level)

🔥 High-Risk Container Misconfigurations

🌍 Real-World Examples (Defensive View)

docker run -v /:/mnt -it ubuntu chroot /mnt bash

docker run --privileged -it ubuntu bash

🔍 Detecting Container Escape Risks

🛡️ Preventing Container Escapes

📋 Secure Docker Run Example

docker run -d \
  --name web-secure \
  --read-only \
  --security-opt=no-new-privileges:true \
  --cap-drop=ALL \
  --cap-add=NET_BIND_SERVICE \
  --cap-add=NET_RAW \
  --user 1000:1000 \
  --tmpfs /tmp:rw,noexec,nosuid,size=128m \
  --tmpfs /var/run:rw,noexec,nosuid \
  --security-opt=apparmor:docker-default \
  nginx:alpine

✅ This container runs as non-root, read-only, with only necessary capabilities, and no new privileges.

🧾 Key Takeaways

• ✔ Docker group = root – Never add users to docker group
• ✔ Privileged containers = host access – Never use --privileged
• ✔ Drop all capabilities – Default containers have too many privileges
• ✔ Read-only + no-new-privileges – Prevents container modification
• ✔ User namespaces – Map container root to unprivileged host user
• ✔ Patch kernels – Most vulnerability-based escapes target kernel flaws

🐳 Docker/Container – Command Awareness (Defensive Auditing)

Commands used by security teams and system administrators to audit container environments. Shown for defensive hardening and verification only.

👥 Docker Group Audit

• Check if current user is in docker group

  groups | grep docker

  If output contains "docker", user has root-equivalent access.
• List all users in docker group

  getent group docker

  Audit quarterly; remove any non-admin users.

🔍 Container Runtime Audit

• List running containers

  docker ps

• Find privileged containers

  docker ps --quiet | xargs -I {} docker inspect {} --format='{{.Name}} Privileged: {{.HostConfig.Privileged}}'

  Privileged: true = CRITICAL finding
• Find containers with host filesystem mounts

  docker ps --quiet | xargs -I {} docker inspect {} --format='{{.Name}} Mounts: {{.HostConfig.Binds}}'

  Mounts containing / or /etc = CRITICAL
• Check dropped capabilities

  docker ps --quiet | xargs -I {} docker inspect {} --format='{{.Name}} CapDrop: {{.HostConfig.CapDrop}}'

  Empty or missing CAP_DROP = excessive privileges
• Check read-only root filesystem

  docker ps --quiet | xargs -I {} docker inspect {} --format='{{.Name}} ReadOnly: {{.HostConfig.ReadonlyRootfs}}'

  ReadOnly: false = writable container filesystem
• Check user namespace

  docker ps --quiet | xargs -I {} docker inspect {} --format='{{.Name}} UsernsMode: {{.HostConfig.UsernsMode}}'

  UsernsMode: host = user namespaces disabled

📦 Image Security Audit

• Scan image for vulnerabilities

  docker scan nginx:latest

  Or use Trivy: trivy image nginx:latest
• Check image user

  docker inspect --format='{{.Config.User}}' nginx:latest

  Blank or "0" = root. Should be non-root user.

🛡️ Remediation Commands (Defensive)

• Remove user from docker group

  sudo gpasswd -d username docker

• Recreate container without privileged mode

  docker run --cap-drop=ALL --cap-add=NET_BIND_SERVICE ...

• Enable user namespace remapping

  # Edit /etc/docker/daemon.json
  {
    "userns-remap": "default"
  }

🛡️ Defender Takeaways

• ✔ Audit weekly: docker group, privileged containers, host mounts
• ✔ Harden: Drop all capabilities, read-only rootfs, no-new-privileges
• ✔ Monitor: Falco/Tracee for runtime container escapes
• ✔ Scan: All images for vulnerabilities and root users