
Docker and Security [pdf] - cujanovic
https://www.ernw.de/download/ERNW_Stocard_Docker-Devops-Security_fbarth-mluft.pdf
======
DyslexicAtheist
"You are absolutely deluded, if not stupid, if you think that a worldwide
collection of software engineers who can't write operating systems or
applications without security holes, can then turn around and suddenly write
virtualization layers without security holes."

\-- Theo de Raadt (on the statement "Virtualization seems to have a lot of
security benefits")

~~~
jron
Theo is wrong with respect to Xen. You might enjoy section 3.1 and 3.2 from
the Qubes Architecture document: [https://www.qubes-
os.org/attachment/wiki/QubesArchitecture/a...](https://www.qubes-
os.org/attachment/wiki/QubesArchitecture/arch-spec-0.3.pdf)

The attack surface of Xen is much smaller than a traditional kernel like
linux. I'm guessing the same can be said for OpenBSD after looking at the
number of system calls.

~~~
detaro
Xen has had it's fair share of vulnerabilities, and the author of the document
you linked also had this to say: [http://lists.xen.org/archives/html/xen-
devel/2015-11/msg0060...](http://lists.xen.org/archives/html/xen-
devel/2015-11/msg00601.html) (follow the links)

~~~
jron
Absolutely. It should also be mentioned that many of the Xen vulnerabilities
are actually due to qemu and that emulation can mostly be avoided by using
PV/PVH.

The Xen attack surface is then reduced to about 20 hypercalls (even less for
ARM).
[http://xenbits.xen.org/docs/unstable/hypercall/index.html](http://xenbits.xen.org/docs/unstable/hypercall/index.html)

~~~
jerdfelt
The number of hypercalls isn't a good indicator of the attack surface area.

As examples:

There is a full x86 instruction decoder which is technically not part of the
hypercall interface. x86 instruction encoding is surprisingly complicated.
There was a vulnerability in that code:
[http://xenbits.xen.org/xsa/advisory-123.html](http://xenbits.xen.org/xsa/advisory-123.html)

Handling x86 page tables and all of the various feature bits is also
surprisingly complicated. This is part of the hypercall interface, but there
was also a vulnerability in that code:
[http://xenbits.xen.org/xsa/advisory-148.html](http://xenbits.xen.org/xsa/advisory-148.html)

------
ThePhysicist
I think we'll see more security incidents involving Docker in the future as it
becomes more popular. I have worked with it for a few months now and I can
already see a few attack vectors that could easily be exploited if the
corresponding Docker features are not used properly.

For example, as Docker can by default mount anything that root can mount,
running

    
    
        docker run -i --volume=/:/data -t ubuntu
    

will give you complete root access to your file system in the docker container
(the talk mentions some Docker features that will mitigate this kind of
attacks, notably UID mapping). Of course no one would willingly do that, but
if you mount user resources into your containers and the resource name
contains something that an external user might control (e.g. his/her
username), then injection attacks become possible. Even with UID mapping
enabled this can leak sensitive information about your host system into the
container. And since people often use containers to run untrusted code (e.g.
for CI systems), this can be a large security threat in my opinion.

Personally I really like Docker and I think it (or similar technologies) will
change many aspects of IT/Devops/Data Analysis in the future, I just think
that maybe they should have some more sensible defaults for security-relevant
settings, i.e. only grant network access to containers if you ask for it,
restrict default memory usage by default, limit the type of volumes you can
mount, etc.

~~~
fpoling
My problem with Docker is that although the advise was always not to run
images with root, in practice all Docker tools defaults to do precisely that
and there are no plans to change the defaults.

At least these days they do provide options to restrict containers so secure
usage is possible (--cap-drop=all is a good start), but still the amount of
efforts to follow good security practices is high.

~~~
raesene4
With 1.10 you can just enable User namespaces, which allows for root in a
container to map to a non-privileged user outside the container, that way it's
a one-time (per instance) change.

~~~
mbreese
While this is a nice security boost once you're in the container, don't you
still need to be root (docker group) in order to _start_ the container? It
honestly doesn't help me much if I have to give users root in order to start a
container, even if they are wrapped inside the container.

~~~
cuckcuckspruce
This is what sudo is for. Give each user access to run their containers (and
only their containers) as a member of the docker group in sudoers.

~~~
mbreese
This doesn't work when users may need to run arbitrary (or user-defined)
containers. You can only sudo so much... But, perhaps you could restrict it to
"sudo docker run". I'll have to give that a try. But that would make it
extraordinarily more difficult for a user to stop / rm / kill a container.
Plus, it's not like docker has the concept of an "owner" for a container -
does it?

Nonetheless, you shouldn't need to run anything as root in order to start a
container that doesn't require extra privileges .

------
tyingq
It's curious to me that of the various container options, only lxc/lxd seems
to put in the effort required to get truly non-privileged containers working
without issues.

Lxc/lxd goes far enough that you can boot a systemd based container, get a
sanely partitioned view of /proc, etc. The effort is non-trivial...they had to
create cgmanager, lxcfs, etc.

Rkt, runc, etc, are all working on it, but don't seem close to a real
solution.

------
geggam
Docker also needs to address the hardcoding of the repo

[https://github.com/docker/docker/issues/1988](https://github.com/docker/docker/issues/1988)

~~~
cyphar
As someone in the issue mentioned that "local registries don't have
authentication", here's a shameless plug for a free software (self-hostable)
replacement for the Docker Hub (which has authentication -- even LDAP support,
and at SUSE we're working on adding token-based authentication and automated
build systems that also rebuild derived images):
[https://github.com/SUSE/Portus](https://github.com/SUSE/Portus). The solution
of "just prepend the registry you use to your image names" is quite
frustrating because it means that pushing and pulling is intertwined with the
names of the things you're pushing and pulling. It should've been implemented
as a flag in the CLI (or even a flag in the daemon for the "default
registry").

------
raesene4
Good presentation. One thing I'd mention is that they talk about the CIS
security guide, but it's currently pretty out of date as it covers 1.6 and
therefore misses a lot of Docker features like Content Trust, User Namespaces
and Seccomp-BPF.

In general I'd say that Docker security is getting better, although I'm really
looking forward to getting a better authentication/authorisation model on the
docker engine as right now it's all or nothing, which is a pretty blunt
instrument. Also this model causes problems when people do things like mount
docker.sock inside a container for introspection as anyone compromising that
container can take over the host. A better authorisation model would allow
safer introspection...

Also worth noting as it's not in the presentation, one of the key Docker
security features, User Namespaces, is not switched on by default, so you need
to enable it on the daemon.

------
merb
I will never get the Docker rant.

At the beginning I loved it however the deeper I digged the more I hated it.
Actually the only thing I need would be immutable infrastructure and resource
isolation. However for most of these things you don't need docker at all. You
would've need some sort of container that could be fully isolated with the
kernel cgroups and have somehow a way to isolate the network, but docker grows
to a extremely fat monolithic approach where everything is put into and still
it gets worse every release and the problems will never be fully addressed.

And on top of that the Docker Inc. tries to monetize on that with software
that other vendors could do as well. Docker Inc. should focus on Docker and
not on everything surrounding that.

Docker should've been easy, but now to make a good use of it your
infrastructure will definitly not as easy as you planned at first. The way how
you deploy software will change, but I doubt that it's docker who will make
the "global" change. Maybe it was docker who gave a first impression how it
could look but it's definitely not the end.

------
code_research
For your convenience here are the URLs from that broken document:

[http://blog.bofh.it/debian/id_413](http://blog.bofh.it/debian/id_413)
[http://reventlov.com/advisories/using-the-docker-command-
to-...](http://reventlov.com/advisories/using-the-docker-command-to-root-the-
host)
[http://events.linuxfoundation.org/sites/events/files/slides/...](http://events.linuxfoundation.org/sites/events/files/slides/Containers,%20Docker,%20and%20Security_%20State%20of%20the%20Union.pdf)
[http://opensource.com/business/14/9/security-for-
docker](http://opensource.com/business/14/9/security-for-docker)
[https://zeltser.com/security-risks-and-benefits-of-docker-
ap...](https://zeltser.com/security-risks-and-benefits-of-docker-application/)
[https://benchmarks.cisecurity.org/tools2/docker/CIS_Docker_1...](https://benchmarks.cisecurity.org/tools2/docker/CIS_Docker_1.6_Benchmark_v1.0.0.pdf)
[https://forums.grsecurity.net/viewtopic.php?f=7&t=2522](https://forums.grsecurity.net/viewtopic.php?f=7&t=2522)
[http://xebia.github.io/cd-with-docker/#/](http://xebia.github.io/cd-with-
docker/#/) [http://www.schibsted.pl/2015/06/how-we-used-docker-to-
deploy...](http://www.schibsted.pl/2015/06/how-we-used-docker-to-deploy-
schibsted-pl/) [http://itrevolution.com/the-three-ways-principles-
underpinni...](http://itrevolution.com/the-three-ways-principles-underpinning-
devops/)

Most of these will be already in your bookmarks, when you are following docker
development.

Why was this talk is interesting? Is there a video that shows things that
happened that are not reflected in the powerpoint pdf? What was new?

BTW the powerpoint document wins the "most annoying document of the week"\-
award. We have better ways to publish URLs in 2016 than powerpoint. Please use
reveal or anything else next time, thanks!

------
pjmlp
Yet another reason to favor unikernels instead.

~~~
__bjoernd
And why would those have no security holes?

Let me see:

* MirageOS runs on Xen. If you break into Xen, you own all unikernels.

* OSv runs on Linux. If you break into Linux, you own all unikernels.

~~~
pjmlp
The fact that Xen is used is just a matter of convenience, nothing forbids
MirageOS to run bare metal if the developers would decide to spend effort
writing device drivers.

However they rather focus in other more critical areas, for the time being.

------
kordless
We're going to need to apply the blockchain to this problem eventually.
Someone call me when we're ready.

------
geggam
does docker still store credentials in cleartext ?

~~~
bigmac
We're working on fixing that in two ways:

1\. Implementing oauth:
[https://github.com/docker/distribution/pull/1418](https://github.com/docker/distribution/pull/1418)

2\. Using credential helpers:
[https://github.com/docker/docker/pull/20107](https://github.com/docker/docker/pull/20107)

------
dang
We changed the url from [https://www.insinuator.net/2016/03/docker-devops-
security/](https://www.insinuator.net/2016/03/docker-devops-security/), which
points to this and doesn't seem to have any content of its own.

