Rebooting within docker container actually reboots the host
CooledCoffee opened this issue · comments
Run docker container with:
docker run -i -t --net host image_id /bin/bash
Then execute reboot. It will actually reboot not the container but the host. This is a potential security problem.
Removing the "--net host" argument, the result is correct:
shutdown: Unable to shutdown system
I think you should never run halt, reboot or shutdown in container, but use docker stop or docker kill command.
What is your docker version?
@hlj
Yes, I shouldn't run reboot in containers. But what if my container is hacked? Or what if I want to run a docker platform (like google compute engine)?
@crosbymichael
I am using the 1.0 version.
What is your kernel version? And exec driver?
Michael Crosby
On Jun 13, 2014, at 7:18 PM, CooledCoffee notifications@github.com wrote:
@hlj
Yes, I shouldn't run reboot in containers. But what if my container is hacked? Or what if I want to run a docker platform (like google compute engine)?@crosbymichael
I am using the 1.0 version.—
Reply to this email directly or view it on GitHub.
@CooledCoffee @crosbymichael wants you to enter the following commands into your shell and paste the output here:
$ uname -a
$ docker info
$ docker version
@crosbymichael as per #6419 he must be using the native driver if he is indeed on 1.0 ;)
smvp@ubuntu:$ uname -aprecise1-Ubuntu SMP Wed Jun 4 22:06:36 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
Linux ubuntu 3.11.0-23-generic #40
smvp@ubuntu:~$ sudo docker info
Containers: 1
Images: 38
Storage Driver: aufs
Root Dir: /var/lib/docker/aufs
Dirs: 40
Execution Driver: native-0.2
Kernel Version: 3.11.0-23-generic
WARNING: No swap limit support
smvp@ubuntu:~$ sudo docker version
Client version: 1.0.0
Client API version: 1.12
Go version (client): go1.2.1
Git commit (client): 63fe64c
Server version: 1.0.0
Server API version: 1.12
Go version (server): go1.2.1
Git commit (server): 63fe64c
I notified the list here: https://groups.google.com/forum/#!topic/docker-user/5pwN8t2QqYA
I think we should take this seriously, so we don't look like gits if it turns out to be real.
ping @shykes
The relevant commits are here:
- https://github.com/dotcloud/docker/pull/4441/files
- https://github.com/dotcloud/docker/pull/5859/files
- https://github.com/dotcloud/docker/pull/6391/files
As you can see, there is nothing obviously wrong with the --net host flag.
This is not entirely unexpected. shutdown works by talking to init and telling it to shut down. In ubuntu init is upstart, and shutdown talks to it by using dbus. If the container shares the net namespace with the host it is allowed to sent messages to init, so nothing prohibits it from changing the runlevel or shutting down the machine.
Not sure what to do about it other than documenting that "host network" actually means the container can talk to all local host services as root, including init.
I think the proper solution there, as in many other similar cases is user namespaces w/ docker-root.
@alexlarsson aha, you're right. And they should be able to start/stop system services and to all sorts of other nasty things :(
@alexlarsson with --net host you would also have full access to any databases running as root and accessible via UDP right?
UDP doesn't do checks on uid. But anything that listens on unix domain sockets do.
It seems that #6088 would fix this problem, and is a solution that would replace the --net host strategy.
@timthelion That does seem like a more secure solution.
I'm not sure, can this be closed now?
FYI: Security vulnerabilities can be disclosed in a responsible manner by sending an email to security@docker.com.
As for the feature, like @alexlarsson explained, it is working by design. The container is the host when it comes to the network stack so any services running on the host are accessible to the container. It just so happens that you communicate to upstart ( and others ) this way.
This feature is a runtime only option, just like the --privileged flag, therefore an image cannot request this, it must be explicitly set at runtime.
We just merged a change to update the documentation around this feature to make it more clear about what you can do. As far as changes pass educating users on this, I don't think there is anything to change about how the feature works. You cannot poke a hole in the side of the container and not expect to give up anything in return.
Is this security issue still a problem if I run the container with --net=host as a non-root user --user="bozo"?
docker run -it --net host luowen/redis sh
2014/08/20 06:48:53 unable to remount sys readonly: unable to mount sys as readonly max retries reached
2014/08/20 14:48:53 Error response from daemon: Cannot start container 0ef205f41b9a6f554a30d735216266b657af7718b29d1c2a5962706cc2fc4692: unable to remount sys readonly: unable to mount sys as readonly max retries reached
what should i do？like that！