Docker Bug Allows Root Access to Host Filesystem

https://decipher.sc/docker-bug-allows-root-access-to-host-file-system

by whiteyford • 7 years ago

144 58 7 years ago

arnon• 7 years ago

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.

Leynos4• 7 years ago

Does your recommendation still stand when Docker used in conjunction with SELinux (and SELinux categories for tennancy isolation)?

dijit• 7 years ago

That seems like lazy contrarianism.

If you put docker inside a VM, and your hypervisor is running in a zone, and you have different zones based on ”role”. Then of course you get the benefits of the zone and the hypervisor.

The parent said “docker solves deployment, not isolation”- if you get your isolation another way then there’s no issue with using docker.

pmlnr• 7 years ago

I wanted to write the same; docker is a packaging solution. It's not a security layer.

baq• 7 years ago

i feel like this is oversimplifying, otherwise we'd be happily running tarballs in chroots. (jails anyone?)

loudmax• 7 years ago

Containerization certainly ought to be an isolation layer to boost security. What's unfortunate is how little we can rely on docker to provide any additional security.

geggam2• 7 years ago

Given that docker is simply an abstraction of the various kernel functions it is arguable that eliminating the docker piece and directly managing the kernel functions would be more secure.

Problem there is it requires a significant learning curve and when you get to that point you start evaluating the ROI of containers. Deployment is easy. Operations is easy. Until either one of the two fail. Then debugging becomes a seriously complex problem.

dobin• 7 years ago

In my opinion, VM's are less secure than containers.

VM's provide a large attack surface, while one CAN restrict containers sufficiently. See contained.af. Doesnt mean Docker does this though.

fwsgonzo• 7 years ago

I'm sorry but that is just false. VMs provide strong isolation which can even be two-way with secure enclaves.

Tepix4• 7 years ago

I think you got it mixed up. The attack surface of a linux kernel is larger than the attack surface of a VM.

Simply speaking, VMs only need to properly take care of a few privileged CPU opcodes.

tapoxi• 7 years ago

An excellent talk from Red Hat's Dan Walsh: https://www.youtube.com/watch?v=a9lE9Urr6AQ

mitchell_h• 7 years ago

https://www.youtube.com/watch?v=hgN8pCMLI2U

Bryan expresses his opinions on this. When you say Isolate that really should include security.

asveikau• 7 years ago

The Unix process, with its uids, is also a form of isolation. But most reasonable people would guess that there are undiscovered privilege escalation bugs in any given kernel and thus be careful who is allowed to put code on a machine.

cyphar3• 7 years ago

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

PyroLagus2• 7 years ago

Apparently even user namespaces can't be trusted for secure isolation, so much so that Arch Linux even has them disabled by default[1]. That said, it's possible that security improved since then, and I don't know when the most recent user namespace vulnerability was found.

[1] https://lists.archlinux.org/pipermail/arch-general/2017-Febr...

djsumdog2• 7 years ago

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)

Tepix4• 7 years ago

Containers' raison d'être is to provide isolation. Just like chroot, they are used for security. If the security mechanism fails, it's good to have defense-in-depth, as usual.

From reading the article it appears the issue is in Docker, not the container mechanism offered by the kernel upon which Docker builds.

laumars4• 7 years ago

Isolation doesn't mean secure. Some containerisation solutions are designed to provide a security mechanism. Other containerisation solutions, such as Docker, are designed as a development and/or orchestration tool.

I do agree that a it's important to have defence in depth

laumars4• 7 years ago

Is that an unpopular opinion? I don't think I see many people who do argue about docker from a security standpoint. At least nobody credible.

Docker has always been sold as more of an development and orchestration tool than a security one.

djsumdog2• 7 years ago

I wrote an article not too long ago, both on Docker orchestration and security:

https://penguindreams.org/blog/my-love-hate-relationship-wit...

nmjohn• 7 years ago

If you believe containers cannot be secure, than you should be able to capture the flag and get paid for beating https://contained.af/

Having said that, I agree that by default containers are a poor security boundary - but saying they are wholesale inadequate is not accurate.

ploxiln• 7 years ago

contained.af uses seccomp to block a bunch of syscalls that you would not block for a real service, for example socket()

cpuguy833• 7 years ago

This is absolutely untrue.

There are things that can be done to enhance the defaults that docker currently provides (b/c defaults are hard to change when you have millions of users), but a process running in a default docker container is absolutely more secure than a process running outside of a container.

esseti• 7 years ago

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?

Leynos4• 7 years ago

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.

hclaria2• 7 years ago

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 !

cyphar3• 7 years ago

https://news.ycombinator.com/item?id=20031403 was the discussion from yesterday to the oss-security post.

nullwasamistake• 7 years ago

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?

hclaria2• 7 years ago

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

https://clearlinux.org/news-blogs/intel-clear-containers-now... https://katacontainers.io/

qalmakka• 7 years ago

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

Tepix4• 7 years ago

KVM requires more resources than LXC (Linux containers).

the84724• 7 years ago

You have more benefits such as sharing resources between containers (page cache, unix sockets, reflink copies, shared memory IPC) etc.

Exposing GPU resources is also a lot easier with containers than with VMs.

Docker Bug Allows Root Access to Host Filesystem

Related Stories