I'm learning a lot about docker. I'm practicing creating docker clusters using docker-swarm, registry, shipyard, etc.

I saw how easy is to get root in a docker host machine once you entered to the host with a limited user which has docker privileges. I was wondering if could be possible instead of this, "escape" from a docker container service to the docker host machine (doesn't care if as root or not).

Can this be done?

Any proof of concept? I was googling and I haven't found anything conclusive.

2 Answers 2


A user on a Docker host who has access to the docker group or privileges to sudo docker commands is effectively root (as you can do things like use docker to run a privilieged container or mount the root filesystem inside a container), which is why it's very important to control that right.

Breaking out of a Docker container to the host is a different game and will be more or less difficult depending on a number of factors. Possible vectors include :-

  • Kernel vulnerabilities. Containers running on a host share the same kernel as the host, so if there's an exploitable issue in the kernel that may be used to break out of the container to the host
  • Bad configuration. If a container that you have access to is running with --privileged you're likely to be able to get access to the underlying host.
  • Mounted filesystems. If a container you have mounts a host filesystem, you can likely change items in that filesystem which could allow you to esclate privileges to the host.
  • Mounted Docker socket. A relatively common (and dangerous) practice in Docker containers is to mount the docker socket inside a container, to allow the container to understand the state of the docker daemon. This allows a trivial breakout to the host. More information here

If you're looking for more information I'd recommend these whitepapers from NCC. Abusing Privileged and Unprivileged Linux Containers and Understanding and Hardening Linix Containers . There's also a presentation I did which covers some of this stuff here.

If you're interested in Docker hardening I'd also recommend having a look at the CIS Security standard.


With normal means, no. Docker was intentionally designed on this security concept.

It uses the namespace functionality of the kernel to separate the processes running in a container from the on host running ones. If a way would be found, it would be considered as a security hole and it would be closed ASAP.

Although there could be system-wide configuration settings. Most typically, docker containers may run with SYS_ADMIN, which essentially means they are capable to change IP addresses, and many other function which is available normally on the host machine. If a container runs with SYS_ADMIN, it is essentially not really more protected as a task running in chroot.

Although this configuration is used mainly if a docker container runs as a service, like a daemon on a Linux server. On normal laptops, as its intended usage, everything runs as default. If it wouldn't be so, the docker users would be had to trust in all of the container developers they are using. Now they only have to trust the docker developers.

On the Windows version of the docker, even this wouldn't be enough. Windows docker starts a Linux VM with HyperV, and runs the docker containers in this Linux VM. Breaking out from a container would only mean a root permission on this VM, to break out to the client you had to find a hole also in the HyperV.

  • 1
    Not sure what CAP_ADMIN you're referring to, SYS_ADMIN? If so that's not one of the default capabilities, (docs.docker.com/engine/reference/run/… ) so unles they add it explicitly with --cap-add or --privileged no docker container will run with that... Commented Mar 5, 2017 at 16:30
  • You would be surprised how many "holes" are there... several common configurations for Docker containers are extremely unsafe and provide no security whatsoever. It is much more reliant on proper configurations than VMs.
    – T. Sar
    Commented Sep 18, 2017 at 17:20
  • @RоryMcCune Yes, I wanted SYS_ADMIN, sorry :-) I fixed it in the post. Yes, it is not a default capability.
    – peterh
    Commented Sep 18, 2017 at 17:29
  • @T.Sar As far I know, Linus personally doesn't really like the containers, however the capabilities are doing well. Why would be so many sechole? As far I know, if a process doesn't have a capability, he has no way to get it back. In the ancient chroot times, there were rumors that it is possible to break out from a chroot as a user, while it is clear that a there is no way to break out from a properly configured chroot. Docker does the same, but also for root processes, with capabilities. How would it be possible to break out? Everything is in namespaces...
    – peterh
    Commented Sep 18, 2017 at 17:31
  • 1
    @Murmel Compared to a VM? The whole point of docker is to not be as isolated as a VM.
    – T. Sar
    Commented Nov 27, 2018 at 19:00

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .