Docker Images on the public registry cannot always be trusted. While they may promise to do one thing unless you spend time to explore the entire image they might have hidden gems designed for malicious activity.

Let's take the image benhall/cute-kittens. This image promises to deliver cute kittens via a Docker Container. Sounds great, so let's run it.

docker run benhall/cute-kittens

The container gave us an error saying that it requires the docker.sock file to launch. As we are keen to run the image, we'll just provide the file:

docker run -v /var/run/docker.sock:/var/run/docker.sock benhall/cute-kittens

However, instead of having the behaviour it expected, it launched a privilege sub-container and performs a ls /dev. The ls command outputs all the devices on the host OS. The container has complete access to these devices.

You can see the results of the additional container being launched by running docker ps -a

If cute-kittens were more malicious, it could have wiped out our entire host.

With Docker and volumes you can define permissions to stop users writing files. However, because the Docker access doesn't override the file, these permissions do not protect you from additional containers being launched.

For example, we're defined that our sock is only read-only, but it will still have the same result.

docker run -v /var/run/docker.sock:/var/run/docker.sock:ro benhall/cute-kittens