Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Docker Bug Allows Root Access to Host Filesystem

decipher.sc

Post reply on HN
Print view View original

51–60 of 60 posts

Re: Docker Bug Allows Root Access to Host Filesystem

#51

Post by cpuguy83 »

geggam wrote: post #36
loudmax wrote: post #7

Earlier quoted context omitted.

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.

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…

There are fairly few vulnerabilities discovered in docker itself. The last one was in runc, the underlying container executor... these are very hard to get right.

This is kind of a stinky one, though because docker runs in the root context (unless you are experimenting with the rootless docker mode).

You could take this same argument to absurd extremes: the kernel is just an abstraction over the hardware, surely you could ditch the kernel and manage the hardware yourself and it will be more secure.

The reality is, in both cases, no you can't. Doing this stuff right requires expertise, and generally need more than one or two people looking at it.

Re: Docker Bug Allows Root Access to Host Filesystem

#52

Post by cpuguy83 »

arnon wrote: post #2

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.

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.

Re: Docker Bug Allows Root Access to Host Filesystem

#53

Post by PyroLagus »

the8472 wrote: post #46
PyroLagus wrote: post #35

Earlier quoted context omitted.

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

That mail is outdated. Arch, like some other distros such as debian, now applies a kernel patch that allows toggling userns support via kernel.unprivileged_userns_clone sysctl.

Oh, I'm aware that you can toggle it via sysctl, but it's still not on by default. That said, I can't find any user namespace CVE from 2019, only 2018, so maybe it's safe enough now. I guess "safe enough" is the keyword. If you really worry about the kernel's attack surface, you'll use a separation kernel, VMs, or separate machines altogether.

Re: Docker Bug Allows Root Access to Host Filesystem

#54

Post by linuxftw »

zantana wrote: post #41
djsumdog wrote: post #37

Earlier quoted context omitted.

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)

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/ 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... using their tools.

And Fedora!

Re: Docker Bug Allows Root Access to Host Filesystem

#55

Post by geggam »

cpuguy83 wrote: post #51
geggam wrote: post #36

Earlier quoted context omitted.

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…

There are fairly few vulnerabilities discovered in docker itself. The last one was in runc, the underlying container executor... these are very hard to get right. This is kind of a stinky one, though because docker runs in the root context (unless you are experimenting with the rootless docker mode). You could take this same argument to absurd extremes: the kernel is just an abstraction over the hardware, surely you…

https://www.cvedetails.com/vulnerability-list/vendor_id-1353...

More than a few, less than a horde

Re: Docker Bug Allows Root Access to Host Filesystem

#56

Post by bepvte »

cpuguy83 wrote: post #50
djsumdog wrote: post #37

Earlier quoted context omitted.

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)

Good news, there is a lot of work on that front, including an official "rootless" distribution: https://get.docker.com/rootless The main thing about it is cgroups are disabled and it requires userspace networking. Here's a write-up on it: https://engineering.docker.com/2019/02/experimenting-with-ro...

As well, you may need to use a fuse based implementation of overlayfs

Re: Docker Bug Allows Root Access to Host Filesystem

#57

Post by ownagefool »

ovi256 wrote: post #38
ownagefool wrote: post #24

Earlier quoted context omitted.

Probably slightly more complicated that. Each and every isolation layer can be broken. Why are we using just one? Run well written software. As a user. In a cgroup. With SELinux. On a VM. On Different Tin. With a security monitoring. Patch.

>Run well written software. As a user. In a cgroup. With SELinux. On a VM. On Different Tin. With a security monitoring. Patch. The analogy you're trying for is surely not that this is as likely to solve the deployement problem for most people just as "Eat food. Not too much. Mostly Plants" is to solve the obesity epidemic for most people ? Not at all ?

No, not most people. Industry professionals deploying applications using frameworks that help with the problem.

I probably wouldn't want a fat PT, the same I don't want my sysadmin to be running apps as root.

Re: Docker Bug Allows Root Access to Host Filesystem

#58

Post by cyphar »

PyroLagus wrote: post #35
cyphar wrote: post #16

Earlier quoted context omitted.

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 contain…

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

The issue is not that user namespaces cannot be used for secure isolation -- the problem is that it has been used for privilege escalation in the past. It definitely is more secure than it was 5+ years ago and there are ways of restricting its use on running systems through a couple of sysctls (in addition to the out-of-tree patch that Debian and Arch use).

But, in the case of running things in containers, you can stop exploits of user namespaces through seccomp filters that block unshare(CLONE_NEWUSER) -- Docker does this by default.

Re: Docker Bug Allows Root Access to Host Filesystem

#59

Post by Leynos »

hclaria wrote: post #28
Leynos wrote: post #8

Earlier quoted context omitted.

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.

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 !

Indeed. The point discussed in the grandparent relates to indirect access to the daemon. E.g., a process (not under direct user control) communicating with the Docker daemon via http API. The point being that the cp endpoint can be compromized without the user having direct control over the API parameters.
Post reply on HN