Is it possible to escalate privileges and escaping from a Docker container?

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.