New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rebooting within docker container actually reboots the host #6401

Closed
CooledCoffee opened this Issue Jun 13, 2014 · 21 comments

Comments

Projects
None yet
8 participants
@CooledCoffee
Copy link

CooledCoffee commented Jun 13, 2014

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

@vieux vieux added this to the 1.0.1 milestone Jun 13, 2014

@hlj

This comment has been minimized.

Copy link

hlj commented Jun 13, 2014

I think you should never run halt, reboot or shutdown in container, but use docker stop or docker kill command.

@crosbymichael

This comment has been minimized.

Copy link
Member

crosbymichael commented Jun 13, 2014

What is your docker version?

@CooledCoffee

This comment has been minimized.

Copy link
Author

CooledCoffee commented Jun 14, 2014

@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.

@crosbymichael

This comment has been minimized.

Copy link
Member

crosbymichael commented Jun 14, 2014

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.

@timthelion

This comment has been minimized.

Copy link
Contributor

timthelion commented Jun 14, 2014

@CooledCoffee @crosbymichael wants you to enter the following commands into your shell and paste the output here:

$ uname -a
$ docker info
$ docker version
@timthelion

This comment has been minimized.

Copy link
Contributor

timthelion commented Jun 14, 2014

@crosbymichael as per #6419 he must be using the native driver if he is indeed on 1.0 ;)

@CooledCoffee

This comment has been minimized.

Copy link
Author

CooledCoffee commented Jun 16, 2014

smvp@ubuntu:$ uname -a
Linux ubuntu 3.11.0-23-generic #40
precise1-Ubuntu SMP Wed Jun 4 22:06:36 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

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

@timthelion

This comment has been minimized.

Copy link
Contributor

timthelion commented Jun 16, 2014

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

@timthelion

This comment has been minimized.

Copy link
Contributor

timthelion commented Jun 16, 2014

The relevant commits are here:

  1. https://github.com/dotcloud/docker/pull/4441/files
  2. https://github.com/dotcloud/docker/pull/5859/files
  3. https://github.com/dotcloud/docker/pull/6391/files

As you can see, there is nothing obviously wrong with the --net host flag.

@alexlarsson

This comment has been minimized.

Copy link
Contributor

alexlarsson commented Jun 16, 2014

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.

@alexlarsson

This comment has been minimized.

Copy link
Contributor

alexlarsson commented Jun 16, 2014

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.

@alexlarsson

This comment has been minimized.

Copy link
Contributor

alexlarsson commented Jun 16, 2014

I think the proper solution there, as in many other similar cases is user namespaces w/ docker-root.

@timthelion

This comment has been minimized.

Copy link
Contributor

timthelion commented Jun 16, 2014

@alexlarsson aha, you're right. And they should be able to start/stop system services and to all sorts of other nasty things :(

@timthelion

This comment has been minimized.

Copy link
Contributor

timthelion commented Jun 16, 2014

@alexlarsson with --net host you would also have full access to any databases running as root and accessible via UDP right?

@alexlarsson

This comment has been minimized.

Copy link
Contributor

alexlarsson commented Jun 16, 2014

UDP doesn't do checks on uid. But anything that listens on unix domain sockets do.

@timthelion

This comment has been minimized.

Copy link
Contributor

timthelion commented Jun 16, 2014

It seems that #6088 would fix this problem, and is a solution that would replace the --net host strategy.

@alexlarsson

This comment has been minimized.

Copy link
Contributor

alexlarsson commented Jun 16, 2014

@timthelion That does seem like a more secure solution.

@crosbymichael crosbymichael self-assigned this Jun 17, 2014

@timthelion

This comment has been minimized.

Copy link
Contributor

timthelion commented Jun 17, 2014

I'm not sure, can this be closed now?

@crosbymichael

This comment has been minimized.

Copy link
Member

crosbymichael commented Jun 17, 2014

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.

@getvictor

This comment has been minimized.

Copy link
Contributor

getvictor commented Jun 20, 2014

Is this security issue still a problem if I run the container with --net=host as a non-root user --user="bozo"?

@MRLuowen

This comment has been minimized.

Copy link

MRLuowen commented Aug 20, 2014

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment