Hacker News Reader

Hacker News

Comment by Lai0chee | Hacker News Reader

Full thread

Lai0chee

humm, the sudo makes me shudder.

View on HN

Why? It's being run inside the docker container, it should be ok.

Docker "isolation" is not as strong as most hipsters think. :-)

Interesting, any links which expand on the issues?

This is the first that comes to mind:

http://blog.bofh.it/debian/id_413

That's an article from 2011. This evasion does not work today.

That example is old, but yes it does work, and will continue to work until docker uses user namespaces.

That said the example is not a good one because of the changes applied these days, e.g. the use of the UID on the host-side.

I actually tried it on Docker 1.2.0 with the ubuntu:14.04 image.

/sys is already mounted and it is read-only, and it cannot be mounted manually:

  root@07ba8c752195:/# mkdir sys2
  root@07ba8c752195:/# mount -t sysfs sysfs /sys2
  mount: block device sysfs is write-protected, mounting read-only
  mount: cannot mount block device sysfs read-only

BTW: Just one example of a typical Linux namespace vulnerability: http://git.kernel.org/cgit/linux/kernel/git/ebiederm/user-na...

I tested this with the busybox image, and received a warning that /sys was already mounted, but the attack then proceded to work as expected.

  kalmi@sylph ~> docker run -t -i busybox:latest
  / # mount -t sysfs sysfs /sys
  mount: permission denied (are you root?)
  / # mkdir sys2
  / # mount -t sysfs sysfs /sys2
  mount: mounting sysfs on /sys2 failed: Permission denied

  kalmi@sylph ~> docker --version
  Docker version 1.2.0, build fa7b24f

  kalmi@sylph ~> uname -r
  Linux sylph 3.13.0-35-generic #62-Ubuntu SMP Fri Aug 15 01:58:42 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

We don't need to argue about this, but I see the same permission-denied issue as you, but that doesn't matter.

The /sys is mounted already and reading/writing to it succeeds:

     / # mount -t sysfs sysfs /sys
     mount: permission denied (are you root?)

     / # echo /var/lib/docker/aufs/mnt/638ae26bb710384a8ebade3a66049277affea8b0f3e96003d351f167a9706aef/tmp/evil-helper > /sys/kernel/uevent_helper

     / # cat   /sys/kernel/uevent_helper
     /var/lib/docker/aufs/mnt/638ae26bb710384a8ebade3a66049277affea8b0f3e96003d351f167a906aef/tmp/evil-helper

From there the attack works. Obviously the change here is that I need to know the full UID, which is a cheat, but ..

Docker is based on Linux namespaces. The first thing which comes to mind is that Docker does not use user namespaces. Hence, the root within Docker is the same root as on the host side. Of course Docker papers over the issue by using apparmor and other tricks but this does not cure the issue itself.

Linux containers (LXC, libvirt-lxc, Docker) are shared kernel visualization. Every single kernel vulnerability will hit you hard.

In contrast to LXC and libvirt-lxc Docker lets you configure a lot of insane setups which are not secure. (But easy to setup) Also keep in mind resource issues. If you setup your container in a wrong way it my eat all your available file descriptors, all memory, etc... (Because it is shared kernel)

Let's face it, the whole technology was not designed for sandboxing, more for easy deployment of applications.

That said, I really love container and use them a lot in production with libvirt-lxc. But I don't use them for sandboxing.

A lot developing in this space. Will have more to talk about soon :)

Reply on news.ycombinator.com