initctl / reboot / shutdown escape containers without network isolation

[stevenschlansker]

Upstart uses an abstract path AF_UNIX socket for initctl to communicate with init:
# define DBUS_ADDRESS_UPSTART "unix:abstract=/com/ubuntu/upstart"

This means that if you run a container (Docker in this case, although I assume not limited to) without network isolation, root in the container has essentially full control of the host system:

root@mesos-slave9-qa-uswest2:~# docker run --net=host ubuntu reboot
ubuntu:latest: The image you are pulling has been verified. Important: image verification is a tech preview feature and should not be relied on to provide security.
Status: Downloaded newer image for ubuntu:latest
FATA[0009] Error response from daemon: engine is shutdown
root@mesos-slave9-qa-uswest2:~# Connection to mesos-slave9-qa-uswest2.qasql.opentable.com closed by remote host.
Connection to mesos-slave9-qa-uswest2.qasql.opentable.com closed.

Arguably, using a filesystem path e.g. "/var/run/upstart/init_socket" would be significantly less confusing and ensure that neither chroots nor containers can so easily escape.

This somewhat relates to #1079711.

[Steve Langasek (vorlon)]

This is by design, *so that* software running inside of chroots can communicate with the running init.

Running software in a container is not secure against host escalations unless you use all of filesystem, network, pid, and uid namespaces.

As Ubuntu has switched to systemd in the latest release and upstart is now idle upstream, even if this were not a deliberate design decision it would not be something we would fix.