42

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.

peterh
  • 2,938
  • 6
  • 25
  • 31
OscarAkaElvis
  • 5,185
  • 3
  • 17
  • 48

2 Answers2

59

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.

Rory McCune
  • 60,923
  • 14
  • 136
  • 217
5

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.

peterh
  • 2,938
  • 6
  • 25
  • 31
  • Not sure what CAP_ADMIN you're referring to, SYS_ADMIN? If so that's not one of the default capabilities, (https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities ) so unles they add it explicitly with `--cap-add` or `--privileged` no docker container will run with that... – Rory McCune Mar 05 '17 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 Sep 18 '17 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 Sep 18 '17 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 Sep 18 '17 at 17:31
  • @perteh Do you remember Heartbleed? How dangerous it was and how stupid was the mistake that caused it? Docker is as strong as you kernel. VMS are strong as the two kernels you are using piled up. Even if something is able to drill out of a VM, it probably will have to deal with a different ecosystem with different settings and different attack surface. Docker reduces isolation from the OS - that always reduces security. – T. Sar Sep 20 '17 at 14:12
  • @T.Sar "Docker reduces isolation from the OS" Why? This is simply not true. – Murmel Nov 26 '18 at 11:30
  • 1
    @Murmel Compared to a VM? The whole point of docker is to not be as isolated as a VM. – T. Sar Nov 27 '18 at 19:00
  • You did not say so, and this is why I say your sentence is simply not true. The whole point of Docker is to build a container which is an isolation based on kernel features, namely cgroups and namespaces – Murmel Nov 28 '18 at 05:49