
Don't expose the docker socket, even to a container - lvh
https://www.lvh.io/posts/dont-expose-the-docker-socket-not-even-to-a-container.html
======
notjack
This assumes that Docker containers are being used like VMs. They're not
designed to allow running isolated arbitrary code in some sort of multi-
tenancy setup, they're designed to isolate dependencies and configuration
between your own deployed services. This is a "security vulnerability" in the
same way that putting up a white picket fence around a jail is - a gross mis-
application of a tool built for a completely different purpose.

~~~
insaneirish
> They're not designed to allow running isolated arbitrary code in some sort
> of multi-tenancy setup

You mean _Linux_ containers are not designed for this, nor are they designed
to be secure. What a sad design failure.

Some [1] container technology was developed with security as a first
principle.

[1]: [http://us-
east.manta.joyent.com/jmc/public/opensolaris/ARChi...](http://us-
east.manta.joyent.com/jmc/public/opensolaris/ARChive/PSARC/2002/174/zones-
design.spec.opensolaris.pdf)

~~~
JoshTriplett
As far as I can tell, Solaris Zones are no more secure than Linux containers;
both use kernel-level isolation mechanisms, while sharing the same kernel
between zones/containers. And thus they both have the same security property:
secure as long as you can't successfully exploit a syscall, but if you can,
you get kernel-level access.

~~~
_delirium
The security property of "secure unless there's an exploit" applies to
basically everything (maybe excluding formally verified software), including
Xen and KVM, so I don't see how that's a specific knock against Zones. Yes, if
there's an exploit that lets you do something you shouldn't be able to do, you
can break out of the container/VM. But, like Xen and KVM, Zones are so far
fairly successfully used as an isolation mechanism for the public cloud, for
some years now. And all three make the claim that you ought to be able to rely
on their isolation mechanisms, and any hole in them will be considered a
serious bug. Whereas the way Docker is using Linux containers doesn't seem
secure enough to make that claim or be used for that purpose, at least not
yet.

~~~
skarap
> Whereas the way Docker is using Linux containers doesn't seem secure
> enough...

Which is totally expected, because docker tries to be useful to the largest
user-base possible. It would be quite harder to use if didn't support
directory mounting (via -v). And it would be a total nightmare for almost
every user if you had to specify a list of allowed syscalls for every
container.

This reminds me the situation with SELinux a lot. It has improved a lot but I
still see "disable SELinux" almost in every tutorial I read on CentOS, Fedora
or RHEL.

~~~
pjmlp
> This reminds me the situation with SELinux a lot. It has improved a lot but
> I still see "disable SELinux" almost in every tutorial I read on CentOS,
> Fedora or RHEL.

Because security is hard.

Just look at the Mac OS X users running as root and disabling Gatekeeper.

Or the developers that stay away from the sandbox model.

One of the nice things of mobile OSes is that there isn't a way around the
container model. Although the history with permissions kind of messes it.

------
benwilber0
Docker is not a sandbox and was never intended to be. A comprehensive SELinux
profile for untrusted Docker containers could be developed, but I've yet to
see one. If you want to run untrusted Docker containers, then this is what you
want.

------
0x400614
I don't understand the point of Docker. It seems like a great product. For any
serious production grade containerization , I'd use a real virtualization
solution like KVM, or VMWare.

~~~
geofft
It's containerization between trustworthy apps; it's not security
containerization. What it gets you is, if you have one application that's
designed to run well on RHEL 5 with /usr/bin/python pointing to Python 2.4,
and another one that's designed to run well on Debian testing with a manual
/usr/bin/python symlink to Python 3, you can give both of them what they want.
This has nothing to do with security.

If you want Docker + security isolation, I'm intrigued by Clear Containers,
which is a lightweight KVM-based virtualization thing:

[https://lists.clearlinux.org/pipermail/dev/2015-September/00...](https://lists.clearlinux.org/pipermail/dev/2015-September/000049.html)

[https://lwn.net/Articles/644675/](https://lwn.net/Articles/644675/)

~~~
takeda
> It's containerization between trustworthy apps; it's not security
> containerization.

Isn't that what a process is? The containers in Linux are based on Jails from
FreeBSD and zones from Solaris. They are absolutely there for security.

Regarding the remaining part of your post, I understand what you are trying to
show but python is a really bad example. You absolutely can have python 2 and
3 side by side, or even different minor versions. And with virtualenv or
pyvenv (that came with 3.4) you can even have multiple installation of the
sane version. If you add setuptools to your application you can easily
generate single file package (I personally like wheel) the deployment is as
simple as writing pip install myawesomeapp-1.0.py2.py3.whl it downloads all
dependencies. There is not much that Docker would help, it only makes things
more complex.

~~~
azernik
virtualenv only works if you want an isolated Python environment. What if you
have two things that each want a set of .so libraries with incompatible
versions, and one wants node.js? In theory this could be managed with
something like NixOS, but containerization is the much more mature and
flexible solution.

~~~
takeda
In that situation you can use LD_LIBRARY_PATH, that's what it is for.

But what you really want in that case is to link the application statically.
If you don't want to have benefits of shared objects:

\- smaller binary \- memory savings (if multiple programs are using the same
library, it is loaded once) \- less files to patch to fix a security
vulnerability

The share objects have these features but it comes at price of lower
performance, so by putting all .so files into a single docker file instead of
statically compiling your application you're getting worst out of both worlds.

~~~
icebraining
Loading .so files doesn't mean the language can be statically compiled.

------
raspasov
Can someone describe a real-attack scenario, using Docker's default settings
as of the latest version? I see a lot of people claiming that it's insecure
but no concrete examples of exploits. I am not saying that it's as secure as
VMs, or that it's inherently secure - I am genuinely* interested and really do
care about this.

*We're in a limited beta of cloudmonkey.io, and we want to run unrelated/untrusted containers side by side securely.

~~~
brianshaler
I assumed that's what the video in the article was about [0], but I haven't
watched it to be sure. Is there anything in particular that isn't clear from
the article? Or are you asking about docker security concerns beyond what this
article is about?

It seems the main point is if there is any way to exploit code running within
a container that has unfettered root access to the host system via the docker
socket, an attacker would then have complete control over the host system.

Exploitation is often mitigated in layers, where if Service A is exploited, an
attacker can only rwx what and where Service A has been granted priveleges to
rwx. That should be as little as possible, the bare minimum access that
service needs to operate. There's no reason your web server or database should
be able to install new programs, create users, etc.

If Service B is running in a container and is given access to write to the
docker socket, suddenly any exploitation of that service opens a door to
immediately have full and unfettered root access to the host system.

> [0] FTA "... ended up making a screencast to unambiguously demonstrate the
> flaw in their setup..."

------
tobbyb
A container is just running a process or chroot in its own namespace. If you
run it as it is you have a single process container like Docker uses, if you
run an init in the namespaced process you have LXC or OS containers that can
support multiple processes like a lightweight VM. [1]

With LXC containers you start them as root and there is no lingering
background LXC process running. Docker also starts containers as root but also
has dockerd hanging around presumably so non root users can interface with it.
But the container process is still running as root so dockerd seems a bit
redundant and unnecesary.

This is because untill recently you couldn't run chroot as non root users and
needed to run containers as root. But 'user namespaces' (> kernel 3.8) changes
this and allows users to run processes in namespaces as a non root user. LXC
has supported unprivileged containers for some time now [2] so you can run LXC
containers as non root users, as in the entire container process is
unprivileged. Docker and Rkt are working on this but its not simple to
implement for container managers as non privileged users cannot access
networking and mounts. But when it does presumably dockerd can run as an
unprivileged process.

But Linux kernel namespaces have not been designed for multi-tenancy for
instance cgroups are not namespace aware, and untill this changes in the
kernel, containers will not provide the level of isolation or security
required for multi-tenant workloads.

And containers managers like LXC or Docker that take these capabilities and
merge them with networking and layered filesystems like aufs or overlayfs
cannot work around this. Parallels OVZ is designed for multi tenancy but the
kernel patch it appears is too large and invasive and doesn't look it will be
merged.

So user namespaces is one level of security and isolation, you can also use
seccomp, app armour, selinux or even grsec. But you have to find the middle
ground between security and usability and given the relative confusion about
containers, namespaces, and container managers it will take time to mature.

[1] [https://www.flockport.com/how-linux-containers-
work/](https://www.flockport.com/how-linux-containers-work/)

[2] [https://www.flockport.com/lxc-using-unprivileged-
containers/](https://www.flockport.com/lxc-using-unprivileged-containers/)

------
skarap
To be honest, exposing host's /var/run/libvirtd.sock to a guest VM will have
exactly the same consistencies.

------
KirinDave
Do... people really offer docker sockets to running containers without
thoroughly vetting them first? Are people really that good at avoiding the
warnings?

I mean, I know it's popular to pass the socket in for automatically re-
configuring proxies... but I haven't seen any serious use outside of that.

------
jayfk
In other news, mounting / gives you access to the root filesystem.

------
alpb
dockerd -- nope. It's `docker -d`

~~~
nailer
'daemonisedthingd' is standard UNIX terminology.

------
codemac
Docker is a rootkit over HTTP.

~~~
voltagex_
>A rootkit is a collection of computer software, typically malicious, designed
to enable access to a computer or areas of its software that would not
otherwise be allowed (for example, to an unauthorized user) while at the same
time masking its existence or the existence of other software.

Doesn't really describe Docker, does it?

~~~
codemac
It does if you're talking about `docker -d` and --privileged.

~~~
KirinDave
Rootkits hide themselves. Docker makes no effort to do so.

I know you're trying to make joke, but it's not funny.

~~~
codemac
That's the joke, literally.

This is a blog post about how docker is insecure when you can get root perms
over a socket the docker daemon exports when you explicitly map it back into a
docker container... as if it's unexpected when it's explicitly docker's design
and the command line you provided.

Oh well, I did think it was funny.

------
hosay123
I don't really get this, the implication is the container becomes more secure
without access to the socket, yet it has access to the hundreds of local
kernel APIs with which on the average month it can easily gain higher
privileges than root, especially on contemporary machines where half the
admins around these days don't even know what a security update looks like

~~~
KirinDave
Why knowingly give a trivial breakout vector to code you don't trust?

