#Docker unix domain socket apk

net=host attaches the container to the host network interface, allowing us to reach other nodes on the cluster. privileged runs the container as root and enables all system calls on the host. $ docker container run -rm -it -privileged -net=host -pid=host -volume /:/mnt nginx chroot /mnt

In case of Alpine-based images just use /bin/sh shell.įinally, we can take control of the Docker host by creating a privileged instance of a container and mounting the host '/' filesystem on it. We can take advantage of the docker.sock exposure within the compromised container to obtain a shell in other containers running on the same node.įirst, run docker container ls to see all the containers that are running on the node.Ĭhoose one of the list and run docker container exec -it /bin/bash to get an interactive shell inside such a container. Other useful commands are docker volume ls and docker secret ls to list the existing volumes and secrets respectively. You can also run docker network inspect to get details about a specific network (IP range, driver, attached containers, etc). You can also run docker service inspect to get details about a specific service (Mounts, IP, etc).Ĥ) Run docker network ls to see all existing networks in the entire cluster. In this environment there are 3 nodes (2 managers + 1 worker).Ģ) Run docker stack ls to know identify many stacks (services of an application) are running across all nodes.ģ) Run docker service ls to get an overview of the services running across all nodes.

#Docker unix domain socket apk

Run apt-get install docker (Debian-based images) or apk add docker (Alpine-based images).īelow, some sample commands to get information about the Swarm cluster.ġ) Run docker node ls to identify how many nodes are in the entire cluster. In order to communicate with the docker.sock, the docker client must be installed inside the container. If so, it will be under the following path: /var/run/docker.sock – as previously explained. Let's see how this is possible.įirst of all, check that docker.sock is mounted inside the container. Therefore, an attacker who compromises such a container can then take control of the whole cluster. It allows the container to communicate directly with the Docker daemon that runs on the host. This demonstrates the large number of projects publicly using this configuration to build a wide variety of clusters:īind mounting the Docker daemon socket gives a lot of power to a container, as it can control the daemon. Searching GitHub for 'docker.sock' shows 267,932 matching results. Even in CI environments – like the ones that use Jenkins – the docker.sock must be exposed to the CI container, in order to give it the capability to start containers (specifically: build, run, sometimes push containers and images). For example, on DataDog the dd-agent user must have permissions to access the docker.sock to get real time logs that are indexed by default. By default, a Unix domain socket (or IPC socket) is created at /var/run/docker.sock.Ī lot of Service Meshes like Consul, and System Monitoring Services like Newrelic and DataDog ask to mount /var/run/docker.sock to collect container information.

The Docker daemon can listen for requests via three different types of sockets: Unix, tcp, and fd. This socket can also be used to communicate with the daemon from within a container.

It is used to communicate with the main Docker daemon by the Docker API and the Docker CLI to execute Docker commands. You have probably been playing with Docker vulnerabilities and realized that in real productive environments, sometimes containers need to bind mount the /var/run/docker.sock file for a variety of purposes.