Skip to content
stellvia.dev

Containers and Namespaces

Determine whether your current root privileges apply to the host or only to a container, and check shared mounts and host sockets. A root prompt alone does not establish an effect on the host.

Commands to check

Section titled “Commands to check”

Additional check examples:

Terminal window
cat /proc/1/cgroup
tr '\0' ' ' < /proc/1/cmdline
tr '\0' '\n' < /proc/1/environ
mount
findmnt
cat /proc/self/mountinfo
ls -ld /.dockerenv /var/run/docker.sock 2>/dev/null
lsns
capsh --print
cat /proc/self/status | grep Cap
docker ps
  • Purpose: Determine the scope of current privileges through PID 1, cgroups, mounts, capabilities, the Docker socket, and internal networks.
  • Prerequisites: docker ps requires access to the Docker socket. Many environments also lack capsh.
  • What to inspect: /.dockerenv, PID 1, OverlayFS, bind mounts, /var/run/docker.sock, capabilities, and reachable internal addresses.
  • Expected output: CapEff: 0000000000000000, mounts sharing the host filesystem, presence or absence of a Docker socket, and addresses of reachable internal services.
  • Interpretation: Root in a container or simulated cloud environment is not necessarily root on the host. Verify host effects through mounts, capabilities, sockets, networks, and changes to actual files.
  • If a check fails: Consider minimal images, namespace differences, restrictions on /proc, rootless containers, and runtimes other than Docker.
  • Alternative commands: ls -la /, hostname, ip route, find /run -maxdepth 2 -type s -ls 2>/dev/null.
  • State change: Read-only. docker ps is normally a read, but access to the Docker socket itself may be audited.

Use getcap from File and Directory Permissions to find file capabilities. Record them separately from a process’s CapEff.

When distinguishing container root from host root, record these points together:

  • A worker’s CapEff may be zero even if a different container appears to run as root. Root inside a simulated cloud API or build container also does not necessarily have host privileges.
  • Before claiming host access, verify the actual path, such as whether a privileged container can modify the host’s core_pattern. Record separately any path that uses credentials found inside a container to log in as a host user.
  • On a shared bind mount, chmod inside a container may change whether a host user can write.
  • When using a kernel or local exploit, record the kernel version, namespace, capabilities, and required kernel modules separately from the exploit name. Obtain CapEff directly with grep Cap /proc/self/status or capsh --print.

Even without a Docker socket, check bind mounts and internal services. Investigate internal listeners under Network and IPC.