
Docker Bug Allows Root Access to Host Filesystem - whiteyford
https://decipher.sc/docker-bug-allows-root-access-to-host-file-system
======
cyphar
[https://news.ycombinator.com/item?id=20031403](https://news.ycombinator.com/item?id=20031403)
was the discussion from yesterday to the oss-security post.

------
arnon
This may be an unpopular opinion, but containers and Docker specifically
shouldn't be used to isolate systems for security.

It should be used to ease deployment.

~~~
cyphar
If you take a look at LXC and LXD, I would very much argue you can use them as
a security boundary. One of the main problems with Docker is that the most
powerful isolation primitive available in Linux -- user namespaces -- is not
used by default and doesn't fully utilise the underlying feature. LXC uses
unprivileged user namespaces by default, and LXD defaults to user namespaces
as well. You can even isolate containers from each other with a basic config
option.

All of that being said, this bug is caused by container runtimes trusting the
rootfs too much. This is something I've been trying to improve but it's
definitely not a trivial problem (lots of things require trusting the
container processes in specific ways due to limitations in the corresponding
kernel APIs -- though I am working on fixing those too).

~~~
djsumdog
I wish it were possible to run Docker as a regular user, or run a separate
Docker in Docker in CI (I assume the Docker CI runners on things like Gitlab
are running as root or shared via `-v
/var/run/docker.sock:/var/run/docker.sock` since Docker-in-Docker is only
recommended for actually developing Docker)

~~~
zantana
Docker is a front end to underlying technologies which do the work.

Red Hat created a Kubernetes compatible set of tools for running Docker
compatible OCI containers called CRI-O [https://cri-o.io/](https://cri-o.io/)
with RHEL/Centos 7.7 and 8+ you can run containers as a regular user:
[https://www.redhat.com/en/blog/preview-running-containers-
wi...](https://www.redhat.com/en/blog/preview-running-containers-without-root-
rhel-76) using their tools.

~~~
linuxftw
And Fedora!

------
nullwasamistake
Why don't people run containers in VM's? I don't get it, the only real selling
point I can come up with for kernel level isolation is ability to over
provision ram. And you shouldn't do that on a server anyways.

It's perfectly possible to fire up a regular docker container inside KVM or
whatever. With constant container security issues, why isn't this the norm?

~~~
hclaria
that's what Intel Clear Containers and KataContainers are trying to do

[https://clearlinux.org/news-blogs/intel-clear-containers-
now...](https://clearlinux.org/news-blogs/intel-clear-containers-now-part-
kata-containers) [https://katacontainers.io/](https://katacontainers.io/)

~~~
qalmakka
And also what Microsoft has been doing since a few years ago on Windows with
Hyper-V isolation.

------
esseti
So, it can be exploited having access to the machine where docker is running
and then using docker cp?

can someone make a real use case of this bug?

~~~
Leynos
The suggestion in the linked post is a situation where the Docker daemon is
being controlled via its API in a multi-tennant environment where user
configuration files are loaded into the container via the cp endpoint. I could
concieve of this being a risk if you allow users to create symlinks in the
location where the configuration files are situated.

~~~
hclaria
Except giving access to a docker daemon equals giving the root access to the
machine

because it's easy to do something such as :

$ docker run -it -v /:/hostfs debian chroot /hostfs

# I'm root !

~~~
the8472
The issue is an unprivileged container fooling the host, not the host
intentionally escalating to root.

