See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/323854483

Docker ecosystem – Vulnerability Analysis

Article in Computer Communications · March 2018

DOI: 10.1016/j.comcom.2018.03.011

CITATIONS READS

120 4,690

4 authors, including:

Simone Raponi Roberto Di Pietro

Centre for Maritime Research and Experimentation (CMRE) King Abdullah University of Science and Technology
42 PUBLICATIONS 564 CITATIONS 359 PUBLICATIONS 9,589 CITATIONS

SEE PROFILE SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Latency-based Identification View project

Cybersecurity on the Edge View project

All content following this page was uploaded by Roberto Di Pietro on 25 March 2018.

The user has requested enhancement of the downloaded file.

 Docker ecosystem – Vulnerability Analysis

A. Martina , S. Raponib , T. Combea , R. Di Pietrob,

{[email protected]/[email protected], [email protected], [email protected], [email protected]}

a Nokia Bell Labs, 1, route de Villejust, 91620 Nozay, France

b HBKU-CSE, Education City, Doha, Qatar

Abstract
Cloud based infrastructures have typically leveraged virtualization. However, the need for always shorter development
cycles, continuous delivery and cost savings in infrastructures, led to the rise of containers. Indeed, containers provide
faster deployment than virtual machines and near-native performance. In this paper, we study the security implications
of the use of containers in typical use-cases, through a vulnerability-oriented analysis of the Docker ecosystem. Indeed,
among all container solutions, Docker is currently leading the market. More than a container solution, it is a complete
packaging and software delivery tool. In this paper we provide several contributions: we first provide a thorough survey
on related work in the area, organizing them in security-driven categories, and later we perform an analysis of the
containers security ecosystem. In particular, using a top-down approach, we identify in the different components of the
Docker environment several vulnerabilities—present by design or introduced by some original use-cases. Moreover, we
detail real world scenarios where these vulnerabilities could be exploited, propose possible fixes, and, finally discuss the
adoption of Docker by PaaS providers.
Keywords:
Security, Containers, Docker, Virtual Machines, DevOps, Orchestration.

1. Introduction achieve their goal of efficiency by reducing the software

overhead imposed by virtual machines (VM) [64] [56] [62],
Virtualization-rooted cloud computing is a mature mar- thanks to a tighter integration of guest applications into
ket. There are both commercial and Open Source driven the host operating system (OS). However, this tighter in-
solutions. For the former ones, one may mention Ama- tegration also increases the attack surface, raising security
zon’s Elastic Compute Cloud (EC2) [7], Google Compute concerns.
Engine [26] [46], VMware’s vCloud Air, Microsoft’s Azure, The existing work on container security [38] [58] [51] [42]
while for the latter ones examples include OpenStack com- focuses mainly on the relationship between the host and
bined with virtualization technologies such as KVM or the container. This focus is completely justified by the fact
Xen. that, while virtualization exposes well-defined resources to
Recent developments have set the focus on two main the guest system (virtual hardware resources), containers
directions. First, the acceleration of the development cycle expose (with restrictions) the host’s resources (e.g., IPC /
(agile methods and devops) and the increase in complexity file-system) to the applications. However, the latter fea-
of the application stack (mostly web services and their ture represents a threat to both confidentiality and avail-
frameworks) trigger the need for a fast, easy-to-use way of ability of applications running on the same host.
pushing code into production. Further, market pressure Containers are now part of a complex ecosystem - from
leads to the densification of applications on servers. This container to various repositories and orchestrators - with
means running more applications per physical machine, a high level of automation. In particular, container solu-
which can only be achieved by reducing the infrastructure tions embed automated deployment chains [17] meant to
overhead. speed up code deployment processes. These deployment
In this context, new lightweight approaches such as con- chains are often composed of third parties elements, run-
tainers or unikernels [54] become increasingly popular, be- ning on different platforms from different providers, raising
ing more flexible and more resource-efficient. Containers concerns about code integrity. This can introduce multi-
ple vulnerabilities that an adversary can exploit to pen-
etrate the system. To the best of our knowledge, while
Personal copy of the authors - paper accepted version.
This paper has been published in ComCom (Elsevier), it can be
deployment chains are fundamental for the adoption of
accessed here: https://doi.org/10.1016/j.comcom.2018.03.011 and containers, the security of their ecosystem has not been
cited as per here. fully investigated yet.
 The vulnerabilities we consider are classified, relatively
to a hosting production system, from the most remote
ones to the most local ones, using Docker as a case study.
We actually focus on Docker’s ecosystem for three rea-
sons. First, Docker successfully became the reference on
the market of container and associated DevOps ecosys-
tem. Indeed, with more than 29 billions of Docker con-
tainer downloads, 900.000 Dockerized apps in the Docker
Hub and 3.000 community contributors [21], Docker is the
world’s leading software container platform. Second, data
protection is still one of the biggest barriers for container
(a) Native
adoption in the enterprise for production workloads [1].
Finally, Docker is already running in some environments
which enable experiments and exploring the practicality of
some attacks.

Contributions. In this paper, we provide several con-

tributions. First, we provide a thorough survey of re-
lated work, classifying them into security-driven cate-
gories. Later, we make a detailed list of security issues re-
lated to the Docker ecosystem, and run some experiments
on both local (host-related) and remote (deployment-
related) aspects of this ecosystem. Further on, we show (b) Type1 hypervisor (c) Type2 hypervisor
that the design of this ecosystem triggers behaviours (cap-
tured in three use-cases) that lower security when com-
pared to the adoption of a VM based solution, such as
automated deployment of untrusted code. This is the con-
sequence of both the close integration of containers into
the host system and of the incentive to scatter the de-
ployment pipeline at multiple cloud providers. Finally, we
argument on the fact that these use-cases trigger and in-
crease specific vulnerabilities, which is a factor rarely taken
into account in vulnerability assessment.

Roadmap. This paper is organized as follows: in Sec- (d) Container (e) Unikernel
tion 2, we provide the background information for virtual-
ization and its alternatives. In Section 3 we survey the re-
Figure 1: Application runtime models
lated work in the area, organizing them in security-driven
categories. We then focus on Docker’s architecture in Sec-
tion 4, including its ecosystem. In Section 5 we outline and cloud computing infrastructure). Given some funda-
Docker’s security architecture. In Section 6, we present mental constraints such as performance overhead, flexi-
Docker’s use cases from several points of view and show bility, and scalability, alternatives to virtualization have
how they differ from VM and other containers (Linux- emerged: unikernels as well as containers. All these ap-
VServer, OpenVZ, etc.) use cases. From these typical proaches are summarized in Fig. 1, and detailed below.
use cases we build, in Section 7, a vulnerability-oriented
risk analysis, classifying vulnerabilities into five categories.
2.1. Virtual machines (VM)
Finally, in Section 8, we discuss the implications of these
vulnerabilities in a cloud-based infrastructure and the is- Virtual machines are the most common way of perform-
sues they trigger. Conclusions are drawn in Section 9. ing cloud computing: they are fully functional OS, run-
ning on top of an emulated hardware layer, provided by
the underlying hypervisor. The hypervisor can either be
2. Technology background running directly on hardware (Fig. 1b) (Xen) or on a host
OS (Fig. 1c) (for instance KVM). VM can be cloned, in-
Cloud applications have typically leveraged virtualiza- stalled within minutes, and booted within seconds, hence
tion, which can also be used as a security component [50] allowing to stack them with centralized tools. However,
(e.g., to provide monitoring of VMs, allowing easier man- the presence of two operating systems (host and guest)
agement of the security of complex cluster, server farms, along with an additional virtual hardware layer introduces
2
significant overhead in performance. Hardware support for shortening the syscalls execution path: they do not em-
virtualization dramatically reduces the cited overhead, but bed drivers and the hypervisor does not emulate a hard-
performance is far from bare metal, especially for I/O op- ware layer. The interaction is achieved through a specific
erations [64] [56] [62]. API, enabling optimizations that were impossible with the
legacy model where an unmodified kernel was running on
2.2. Containers top of emulated hardware [37]. However, these modifica-
tions make unikernels dependent on the hypervisor they
Containers (Fig. 1d) provide near bare metal per- run on. Indeed, currently most unikernels development
formance as opposed to virtualization (fig. 1a and are bound to the Xen hypervisor. Furthermore, uniker-
1b) [64] [56] [62] with the further possibility to run seam- nels are usually designed to run programs written in a
lessly multiple versions of applications on the same ma- specific programming language. Thus, they only embed
chine. For instance, new instances of containers can be the libraries needed by this specific language and are opti-
created quasi-instantly to face a customer demand peak. mized for this specific language (e.g., HaLVM for Haskell,
Containers have existed for a long time under various OSv for Java). It decreases the induced overhead rela-
forms, which differ by the level of isolation they provide. tively to a VM. A detailed performance comparison of
For example, BSD jails [48] and chroot can be considered OSv against Docker and KVM is currently available [56].
as an early form of container technology. As for recent A study on this topic [37] shows that unikernels achieve
Linux-based container solutions, they rely on a kernel sup- better performance than VM, and addresses some of the
port, a userspace library to provide an interface to syscalls, security concerns containers suffer from. This is possi-
and front-end applications. There are two main kernel im- ble since applications running in unikernels do not share
plementations: LXC-based implementation, using cgroups the host OS kernel. The study concludes that unikernels
and namespaces, and the OpenVZ patch. The most pop- implementations are not mature enough for widespread
ular implementations and their dependencies are shown in deployment in production. However, latest developments
Table 1. consider unikernels as a serious concurrent to containers
Containers may be integrated in a multi-tenant environ- in the longer term [54] [53], both for security reasons and
ment, thus leveraging resource-sharing to increase average for their significantly short startup time.
hardware use. This goal is achieved by sharing the ker-
nel with the host machine. Indeed, in opposition to VM, 2.4. Comparison
containers do not embed their own kernel but run directly Each of these alternatives provides a different trade-off
on the host kernel. This shortens the syscalls execution between multiple factors, including performance, isolation,
path by removing the guest kernel and the virtual hard- boot time, storage, OS adherence, density and maturity.
ware layer. Additionally, containers can share software Most of these factors are performance-related, but security
resources (e.g., libraries) with the host, avoiding code du- and maturity of the solutions are also at stake. According
plication. The absence of kernel and some system libraries to the relative importance of these factors, and driven by
(provided by the host) makes containers very lightweight the intended use, one specific solution may be preferred.
(image sizes can shrink to a few megabytes). It makes On the one hand, traditional VM are quite resource-
the boot process very fast (about one second [65]). This consuming and slow to boot and deploy. However, they
short startup time is convenient to spawn containers on- provide a strong isolation that has been experienced in
demand or to quickly move a service, for instance when im- production for many years. On the other hand, contain-
plementing Network Function Virtualization (NFV). The ers are lightweight, very fast to deploy and boot, impose
deployment of such containers —agnostic of each other low performance overhead —at the price of less isolation—
even though running on the same shared kernel— requires and provide a new environment with almost no feedback
isolation. from production uses. Unikernels try to achieve a compro-
In sections 4, 5, 6 and 7, we will discuss the cgroups mise between VMs and containers, providing a fast and
and namespaces based containers, and especially Docker’s lightweight —but still experimental— execution environ-
containers. Indeed, Docker popularity, coupled with the ment running in an hypervisor.
extended privileges on the machines it is run, make it a
target with a high payoff for any adversary, and that is 3. Related work
why we concentrate on the vulnerabilities it is subject to,
and possible countermeasures. In this section we provide a thorough survey on related
work in the area. We first describe the studies that provide
2.3. Unikernels a comparison between containers and virtualization tech-
niques. Then we organize the related work into security-
Unikernels consist of very lightweight operating systems driven groups according to the type of security contribu-
(OS), specifically designed to run in VM (Fig. 1e). Uniker- tion provided (i.e., security aspects of containers, defense
nels were originally designed to run on the Xen hypervi- against specific attacks, vulnerability analysis, and use-
sor [34]. They are more performant than classical VM by case driven vulnerability analysis).
3
 Table 1: Container solutions

Base Container Library Kernel dependence Other dependencies

cgroups + namespaces + capabilities iptables, perl, Apparmor,
Docker libcontainer
+ kernel version 3.10 or above sqlite, GO
LXC liblxc cgroups + namespaces + capabilities GO
LXC LXD liblxc cgroups + namespaces + capabilities LXC, GO
cgroups + namespaces + capabilities
Rocket AppContainer cpio, GO, squashfs, gpg
+ kernel version 3.8 or above
Warden custom tools cgroups + namespaces debootstrap, rake
specific components: CRIU,
OpenVZ OpenVZ libCT patched kernel
ploop, VCMMD

Container and virtualization comparison and compare a selection of OS-level virtualization solutions
A comparison between containers and virtualization is with respect to this model.
provided in [43]. This article is a general-purpose sur- Bacis et al. in [35] focuses on SELinux profiles manage-
vey of containers, showing containers concepts, pros and ment for containers. The authors propose an extension to
cons, and detailing features of some container solutions. It the Dockerfile specification to let developers include the
concludes on the prediction (the paper dates back to 2014) SELinux profile of their container in the built image, to
that containers will be a central technology for future PaaS simplify their installation on the host. This solution at-
solutions. However, the comparison is essentially made on tempts to address the problem that the default SELinux
a performance basis, and the only security concern men- Docker profile gives all containers the same type, and all
tioned is the need for a better isolation between containers. Docker objects the same label, so that it does not protect
A thorough performance evaluation of virtualization and containers from other containers [55].
containerization technologies —Docker, LXC, KVM, OSv
(unikernel)— is provided in [56]. The authors use mul- Defense against specific attacks
tiple benchmark tests (Y-Cruncher, NBENCH, Noploop, With the wide spread usage of containerization tech-
Linpack, Bonnie++, STREAM, Netperf) to assess CPU, nology, numerous articles related to specific defenses have
memory and network throughput and disk I/O in differ- come to light. Given that containers can directly commu-
ent conditions. They show that containers are significantly nicate with the kernel of the host, an attacker can perform
better than KVM in network and disk I/O, with perfor- several escape attacks in order to compromise both the
mance almost equal to native applications. They conclude container and the host environment. Once out of the con-
by mentioning security as the trade-off of performance tainer, she has the potential to cause serious damages by
for containers. A similar performance evaluation is made obtaining rights through privilege escalation techniques or
in [44]. by causing the block of the system (and therefore of all
the related containers hosted) making use of DoS attacks.
Security aspects of containers In [47], the authors analyze Docker escape attacks and
The security aspect of containers is discussed in more de- propose a defense method that exploits the status names-
tail in [38]. This article details Docker’s interaction with paces. This method provides for a dynamic detection of
the underlying system, e.g., on the one hand internal se- namespace status at runtime (i.e., during the execution
curity relying on namespaces and cgroups, intended and of the processes). The resulting monitoring is able to de-
achieved isolation, and per-namespace isolation features. tect anomalous processes and can prevent their escape be-
On the other hand, it details operating system-level secu- haviours, increasing the security and the reliability of the
rity, including host hardening (with a short presentation container operations. In [40] the authors proposes a tech-
of Apparmor and SELinux) and capabilities. The authors nique based on the limitation of container memory to re-
insist on the need to run containers with the least privi- duce the Docker attack surface and protects the container
lege level (e.g non-root) and conclude that with this use technology from DoS attacks.
and the default Docker configuration, containers are fairly
safe, providing a high level of isolation. Vulnerability Analysis
A security-driven comparison among Operating System- In [45], the authors provide an analysis of the con-
level virtualization systems is provided in [58]. In the ap- tent of the images available to download on the Docker
proach of OS-level virtualization, a number of distinct user Hub, from a security point of view. The authors show
space instances (often referred to as containers) are exe- that a significant amount of official and unofficial images
cuted on top of a shared operating system kernel. The on the Docker Hub embed packages with known security
authors propose a generic model for a typical OS-level vir- vulnerabilities, that can therefore be exploited by an at-
tualization setup with the associated security requirements tacker. Detailed results show that 36% of official images
4
contain high-priority CVE vulnerabilities, and 64% con- (the Docker Hub: Fig. 2 - component c), and other un-
tain medium or high-priority vulnerabilities. Another re- official repositories (Fig. 2 - component d), along with a
cent work related to the vulnerabilities inside the images trademark (Docker Inc.) and bindings with third parties
of Docker Hub is described in [61]. The authors of the applications (Fig. 2 - component e). The build process im-
paper analyze the Docker Hub images by using the frame- plies fetching code from external repositories (containing
work DIVA (Docker Image Vulnerability Analysis). With the packages that will be embedded in the images: Fig. 2
the analysis of exactly 356.218 images they show that both - component g). An orchestrator (Fig. 2 - component f)
official and unofficial images have more than 180 vulner- can be used for managing the lifecycle of the operational
abilities on average. Furthermore, many images have not infrastructure.
been updated for hundreds of days and the vulnerabili- The Docker project is written in Go language and was
ties commonly tend to propagate from parent images to first released in March 2013. Since then, it has experienced
child ones. Lu et al. in [52] the authors study the typi- an explosive diffusion and widespread adoption [21].
cal penetration testing process under Docker environment
related to common attacks such as DoS, container escape
and side channel. A. Mouat, in [57], provides an overview
of some container vulnerabilities, such as Kernel exploits,
DoS attacks, container breakouts, poisoned images, and
compromising secrets. The study describes the Docker
technology and provides security tips in order to limit the
related attack surface. Although some vulnerabilities in
our paper are common to those of the book, our work
faces them from a different point of view (e.g., both works
analyze the vulnerabilities inside the images but only ours
considers the vulnerabilities due to the image automatic
construction starting from the software development plat-
form GitHub). Besides, in our work we study the security
implications of the use of containers taking into account
the typical use-cases.

Use-cases driven vulnerability analysis

To the best of our knowledge, our work is the first one
that provides a use-cases driven vulnerability analysis.
We evaluate the impact of vulnerabilities in the three
most used use-cases: Docker recommended use-case,
wide-spread use-case (e.g., casting containers as Virtual
Machines), and Cloud Provider CaaS use-case. The
approach is new since it does not directly concern the
Docker software but the code distribution process.

The same authors of this paper have produced a

magazine article [41] addressing (at a magazine level) just
a subset of the topics discussed here.

4. Docker Figure 2: Overview of the Docker ecosystem. Arrows show code

path, with associated commands on them (docker <action>)
In this section, Docker’s ecosystem and main compo-
nents, i.e., specification, kernel support, daemon, Docker
Hub and dedicated OS that emerged around Docker, are 4.1. Docker specification
presented. The specification’s scope is container images and run-
The term Docker is overloaded with a few meanings. It time.
is first a specification for container images and runtime, Docker images are composed of a set of layers along
including the Dockerfiles allowing a reproducible building with metadata in JSON format. They are stored at
process (Fig. 2 - component a). It is also a software that /var/lib/docker/<driver>/ where <driver> stands for
implements this specification (the Docker daemon, named the storage driver used (e.g., AUFS, BTRFS, VFS, De-
Docker Engine: Fig. 2 - component b), a central reposi- vice Mapper, OverlayFS). Each layer contains the modi-
tory where developers can upload and share their images fications done to the file-system relatively to the previous
5
 in the kernel, each one addressing a specific aspect of the
system [29]:

• PID: provides a separate process tree with PID num-

bers relative to the namespace (two processes in differ-
ent namespaces can have the same local PID). Each
PID in a namespace is mapped to a unique global
PID.

Figure 3: Example of image inheritance trees • IPC (inter-process communication): provides POSIX
message queues, SystemV IPC, shared memory, etc..

layer, starting from a base image (generally a lightweight • NET: provides network resources — each NET names-
Linux distribution). This way, images are organized in pace contains its own network stack, including inter-
trees and each image has a parent, except from base im- faces, routing tables, iptables rules, network sockets,
ages that are roots of the trees (Fig. 3). This structure etc..
allows to ship in an image only the modifications specif- • MNT: provides file-system mountpoints: each con-
ically related to that image (app payload). Therefore, if tainer has its own view of the file-system and mount
many images on a host inherit from the same base im- points —like an enhanced chroot— in order to avoid
age, or have the same dependencies, they will be fetched path traversals, chroot escapes, or information leak /
only once from the repositories. Additionally, if the local injection through /proc, /sys and /dev directories.
storage driver allows it (with a union file-system, i.e., a
read-only file system, and some sort of writable overlay on • UTS: provides hostname and domain isolation.
top [63]), it will be stored only once on the disk, leading
to substantial resource savings. The detailed specification • USER: provides a separate view of users and groups,
for Docker images and containers can be found at [20]. including UIDs, GIDs, file permissions, capabilities...
Images metadata contain information about the im-
• CGROUP: provides a virtualization of the process’
age itself (e.g., ID, checksum, tags, repository, author...),
cgroups view — each cgroup namespace has its own
about its parent (ID) along with (optional) default run-
set of cgroup root directories, that represents its base
time parameters (e.g., port re-directions, cgroups config-
points.
uration). These parameters can be overridden at launch
time by the docker run command. Each of these namespaces has its own kernel internal ob-
The build of images can be done in two ways. It is possi- jects related to its type, and provides to processes a local
ble to launch a container from an existing image (docker instance of some paths in /proc and /sys file-systems. For
run), perform modifications and installations inside the instance, NET namespaces have their own /proc/net di-
container, stop the container and then save the state of rectory. A thorough list of per-namespace isolated paths is
the container as a new image (docker commit). This pro- provided by [29] and their isolation role is detailed in [58].
cess is close to a classical VM installation, but has to be New namespaces can be created by the clone() and
performed at each image rebuild (e.g., for an update); since unshare() syscalls, and processes can change their current
the base image is standardized, the sequence of commands namespaces using setns(). Processes inherit namespaces
is exactly the same. To automate this process, Docker- from their parent. Each container is created within its own
files allow to specify a base image and a sequence of com- namespaces. Hence, when the main process (the container
mands to be performed to build the image, along with entry point) is launched, all container’s children processes
other options specific to the image (e.g., exposed ports, are restricted to the container’s view of the host.
entry point...). The image is then built with the docker cgroups are a kernel mechanism to restrict the resource
build command, resulting in another standardized tagged usage of a process or group of processes. They prevent
image that can be either run or used as a base image for a process from taking all available resources and starving
another build. The Dockerfile reference is available in [25]. other processes and containers on the host. Controlled
resources include CPU shares, RAM, network bandwidth,
4.2. Docker internals and disk I/O.
Docker containers rely on creating a wrapped and con-
trolled environment on the host machine in which arbi- 4.3. The Docker daemon
trary code could (ideally) be run safely. This isolation The Docker software itself (Fig. 2b) runs as a daemon on
is achieved by two main kernel features, kernel names- the host machine. It can launch containers, control their
paces [36] and control groups (cgroups). Note that these level of isolation (cgroups, namespaces, capabilities restric-
features were merged starting from the Linux kernel ver- tions and SELinux / Apparmor profiles), monitor them to
sion 2.6.24 [2]. There are currently 7 different namespaces trigger actions (e.g restart) and spawn shells into running
6
containers for administration purposes. It can change ipt- 4.6. Docker dedicated operating systems
ables rules on the host and create network interfaces. It is
In addition to the Docker package in mainstream dis-
also responsible for the management of container images:
tributions, a number of dedicated distributions have been
pull and push images on a remote registry (e.g the Docker
developed specifically to run Docker or other container so-
Hub), build images from Dockerfiles, sign them, etc.. The
lutions. They allow running Docker on host OS other than
daemon itself runs as root (with full capabilities) on the
Linux when run inside a VM, without the complexity of
host, and is remotely controlled through a UNIX socket.
a full Linux distribution. We experimented three of these
The ownership of this socket determines which users can
distributions:
manage containers on the host using the docker command.
Alternatively, the daemon can listen on a classical TCP • Boot2docker [10], a distribution based on TinyCore-
socket, enabling remote container administration without Linux, meant to be very lightweight (the bootable .iso
requiring a shell on the host. weights 27MiB). It is mainly used to run Docker con-
tainers on OS other than Linux (e.g., running in Vir-
4.4. The Docker Hub tualBox on Windows Server). The security advantage,
The Docker Hub (Fig. 2c) is an online repository that when compared to mainstream distributions, is the re-
allows developers to upload their Docker images and let duced attack surface due to the minimal installation.
users download them. Developers can sign up for a free ac-
• CoreOS [12], a distribution dedicated to containers.
count, in which all repositories are public, or for a pay ac-
It can run Docker, along with Rocket, for which it
count, allowing the creation of private repositories. Repos-
was designed. Rocket is a fork of Docker that only
itories from a developer are namespaced, i.e., their name
runs containers: in opposition to the monolithic de-
is “developer/repository”. There also exist official repos-
sign of Docker, interaction with the ecosystem and
itories, directly provided by Docker Inc, whose name is
image builds are managed by other tools in CoreOS.
“repository”. These official repositories stand for most
The OS integrates with Kubernetes [28] to orchestrate
used base images to build containers. They are “a curated
container clusters on multiple hosts.
set of Docker repositories that are promoted on Docker
Hub” [19]. • RancherOS [31], an OS entirely based on Docker,
The Docker daemon, along with the Docker Hub and meant to run Docker containers. The init process is
the repositories are similar to a package manager, with a Docker daemon (system-docker) and system ser-
a local daemon installing software on both the host and vices run in (privileged) containers. One of these ser-
the remote repositories. Some of the repositories are offi- vices is another Docker daemon (user-docker) that
cial while others are unofficial, provided by third parties. spawns itself user-level containers. All installed ap-
From this point of view, the Docker Hub security can be plications on the system run in Docker containers, so
compared to that of a classical package manager [39]. This that Docker commands are used to install and update
similarity guided our vulnerability analysis study in Sec- software on the host. No external package manager is
tion 7. required.

4.5. The Docker Store

5. Docker containers security architecture
The Docker Store [23] is an online self-service portal
that allows Docker developers to sell and distribute their By construction, Docker security relies on three compo-
Docker images to Docker users. The Store contains free nents: 1.) isolation of processes at userspace level man-
and open-source images, as well as software directly sold aged by the Docker daemon; 2.) enforcement of the cited
by publishers. Every user can sign for a free account and mechanism at kernel level; and, 3.) network operations
can both download freeware images, or purchase premium security. In the following section, we develop each compo-
ones. Users can also become publishers to share their nent.
Docker images, hence getting several benefits. Among the
many, publishers have greater visibility, the possibility to
5.1. Isolation
achieve the Docker certified quality marks, the possibility
to use the Docker Store licensing support (to limit ac- Docker containers rely exclusively on Linux kernel fea-
cess to their software based on the type of users), and tures, including namespaces, cgroups, hardening and ca-
a communication channel with the customers, i.e., every pabilities. Namespace isolation and capabilities drop are
customer is notified in case of Docker image updates or enabled by default, but cgroup limitations are not, and
upgrades. Although Docker has just its own registry for must be enabled on a per-container basis through -a -c
containers (Docker Hub), the Docker Store is specifically options on container launch. The default isolation configu-
oriented to the needs of enterprises. It offers enterprises ration is relatively strict, the only flaw is that all containers
with commercially supported software from trusted and share the same network bridge, enabling ARP poisoning
verified publishers. attacks between containers on the same host.
7
 However, the global security can be lowered by op- key compromise, mitigate replay attacks by embedding ex-
tions, triggered at container launch, giving (to con- piration timestamps in signed images, etc.. The trade-off
tainers) extended access to some parts of the host is a complex management of keys. It actually implements
(--uts=host, --net=host, --ipc=host, --privileged, a PKI where each developer owns a root key (“offline key”)
--cap-add=<CAP>, etc.). These features enhance contain- that is used to sign (“signing keys”) Docker images. The
ers convenience, enabling containers to interact with the signing keys are shared among every entity needing to issue
host system at the price of introducing possible vulnera- an image (possibly including automated signatures in an
bilities. For example, when given the option --net=host automated code pipeline, meaning that third-parties have
at container launch, Docker does not place the container access to the keys). The distribution of the (numerous)
into a separate NET namespace and therefore gives the root public keys is also an issue.
container full access to the host’s network stack (enabling The daemon is remote-controlled through a socket. By
network sniffing, reconfiguration, etc.). default, the socket used to control the daemon is a UNIX
Additionally, security configuration can be set glob- socket, located at /var/run/docker.sock and owned by
ally through options passed to the Docker dae- root:docker. Access to this socket allows to pull and run
mon. This includes options lowering security, like the any container in privileged mode, therefore giving root ac-
--insecure-registry option, disabling TLS certificate cess to the host. In case of a UNIX socket, a user member
check on a particular registry. Options increasing security of the docker group can gain root privileges, and in case
are available, such as the --icc=false parameter, that of a TCP socket, any connection to this socket can give
forbids network communications between containers and root privileges to the host. Therefore the connection must
mitigates the ARP poisoning attacked described before. be secured with TLS (--tlsverify). This enables both
However, they prevent multi-container applications from encryption and authentication of the two sides of the con-
operating properly, hence are rarely used. nection (while adding additional certificate management).

5.2. Host hardening

6. Typical Docker use-cases
Host hardening through Linux Security Modules is a
means to enforce security related limitations constraints Most of the security discussions about containers com-
imposed to containers (e.g., compromise of a container pare them to VMs, thus assuming both technologies are
and escape to the host OS). Currently, SELinux, Appar- equivalent in terms of design. Although VMs equiv-
mor and Seccomp are supported, with available default alence is the aim of some container technologies (e.g.,
profiles. These profiles are generic and not restrictive (for OpenVZ used to spawn Virtual Private Servers), recent
instance, the docker-default Apparmor profile [5] allows “lightweight” container solutions such as Docker were de-
full access to file-system, network and all capabilities to signed to achieve completely different objectives than the
Docker containers). Similarly, the default SELinux policy ones achieved by VMs [4]. Therefore, it is a key point to
puts all Docker objects in the same domain. Therefore, develop the Docker typical use-cases here, as an introduc-
default hardening does protect the host from containers, tion to the vulnerability analysis and to put the vulnera-
but not containers from other containers. This must be bilities (Section 7) in perspective of each context.
addressed by writing specific profiles, that depend indi- We can distinguish three types of Docker usages:
vidually on the containers.
SELinux experiments were conducted in 2012 on LXC • Recommended use-case, i.e., the usages Docker was
containers [55], showing that the default SELinux profile designed for, as explained in the official documenta-
gives all containers the same type, and all objects the same tion;
label. This configuration does not protect containers from • Wide-spread use-case, i.e., the common usages done
other containers. by application developers and system administrators;

5.3. Network security • Cloud provider’s CaaS use-case, i.e., the usages guided
by the Cloud providers implementations to cope with
Network resources are used by Docker for image distri-
both security and integration within their infrastruc-
bution and remote control of the Docker daemon.
ture.
Concerning image distribution, images downloaded from
a remote repository are verified with a hash, while the con-
nection to the registry is made over TLS (except if explic- 6.1. Recommended use-case
itly specified otherwise). Moreover, starting from version Docker developers recommend a micro-services ap-
1.8 issued in August 2015, the Docker Content Trust [16] proach [15], meaning that a container must host a single
architecture allows developers to sign their images before service, in a single process (or a daemon spawning chil-
pushing them to a repository. Content Trust relies on TUF dren). Therefore a Docker container is not considered as
(The Update Framework [60]). It is specifically designed to a VM: there is no package manager, no init process, no
address package manager flaws [39]. It can recover from a sshd to manage it. All administration tasks (container
8
stop, restart, backups, updates, builds...) have to be per- processes in the containers). Then, with containers embed-
formed via the host machine, which implies that the le- ding enough software to run a full system (logging daemon,
gitimate containers admin has root access to the host. ssh server, even sometimes an init process), it is tempting
Indeed, Docker was designed to isolate applications that to perform administration tasks from within the container
would otherwise run on the same host, so this root access itself. This is completely opposed to Docker’s design. In-
is assumed to be granted. From a security point of view, deed, some of these administration tasks need root access
isolation of processes (through namespaces) and resources to the container. Some other administration actions (e.g.,
management (through cgroups) makes it safer to deploy mounting a volume in a container) may need extra capa-
Docker applications compared to not using container tech- bilities that are dropped by Docker by default. This kind
nology but rather usual processes on the host. of usage tends to increase the attack surface. Indeed, it
The main advantage of Docker is the ease of applica- enables more communication channels between host and
tion deployment. It was designed to completely separate containers, and between co-located containers, increasing
the code plane from the data plane: Docker images can the risk of attacks, such as privilege escalation.
be built anywhere through a generic build file (Dockerfile) Eventually, with the acceleration of software develop-
which specifies the steps to build the image from a base ment cycles allowed by Docker, developers cannot main-
image. This generic way of building images makes the tain each version of their product and only maintain the
image generation process and the resulting images almost latest one (tag “latest” on Docker repositories). As a con-
host-agnostic, only depending on the kernel and not on sequence, old images are still available for downloading,
the installed libraries. The considerable effort and associ- but they have not been updated for hundreds of days and
ated benefits of adopting the micro-services approach are can introduce several vulnerabilities [61]. A study [45] has
developed in [49]. Airpair [24] lists eight proven real world shown that more than 30% of images on the Docker Hub
Docker use cases, that fit in the official recommendations: contain high severity CVE vulnerabilities, and up to 70%
contain high or medium severity vulnerabilities.
• Simplifying configuration; Note that these images cannot always be reproducibly
built: although the Dockerfile is public on the Docker Hub,
• Code pipeline management;
it often includes a statement ADD start.sh /start.sh or
• Developer productivity; similar, that copies an install script from the maintainer’s
computer (and not available on the Dockerhub) to the im-
• App isolation; age and runs it, without appearing in the Dockerfile. Some
• Server consolidation; maintainers even remove this script after execution.

• Debugging capabilities; 6.3. Cloud providers CaaS use-case

In this section, we present the integration of Docker as
• Multi-tenancy; and, provided by the main Cloud Providers. We focused on
• Rapid deployment. Amazon Web services, Google Container Engines, and Mi-
crosoft Azure as they are three market leaders. Further,
we experimented on them as per the provided level of se-
6.2. Wide-spread use-case
curity, and results are reported in the following.
According to Forrester consulting [1], one of the main Amazon provides a recent support for Docker contain-
reasons for adopting containers is to increase developers ers in its Elastic Compute Cloud (EC2) orchestration tool
efficiency rather than favoring micro-service architectures (generally available since April 2015). It allows users to
(i.e., the recommended use-case). In fact, two of the most launch containers in EC2 VM instances and to control
popular images on Docker Hub are Ubuntu (by far) and them with a dedicated interface (EC2 Container Service
CentOS [18], two VM-oriented container images. Some (ECS)). Users must first create VM from their EC2 ac-
sysadmins or developers use Docker as a way of shipping count, install Docker and the ECS daemon on them, reg-
complete virtual environments and updating them on a ister them to their ECS cluster, and, finally, they can
regular basis, casting containers’ usage as VM [6]. Al- launch Docker containers via the web interface [7] or via a
though this is convenient since it limits system adminis- command-line tool. Concerning Docker security, the host
tration tasks to the bare minimum (e.g., docker pull), it configuration is up to the users since the host is an EC2
has several security implications. First, embedding more instance, i.e., a VM. Standard images do not provide ei-
software than the payload the container was designed for, ther Apparmor or SELinux (but they can be installed) and
increases the attack surface of resulting container images. the host network configuration is dependent on the EC2
Additional packages and libraries could lead to vulnera- private cloud [7].
bilities that would otherwise be avoided. Moreover, this Similarly, Google provides support for Docker in its
software bloat makes containers management more com- Compute Engine infrastructure. It has recently issued its
plex and leads to wasted resources (e.g., larger images, Kubernetes orchestrator [28]. It allows to automatically
more bandwidth and storage needed do deploy them, more create a cluster of VM on which Docker is installed and
9
configured, running on a private overlay network. Con- global. Using the replicated service, the user must spec-
tainers are grouped in “pods”: sets of containers sharing ify the number of identical tasks she wants to run. A
the same NET namespace (and so interfaces and IP ad- global service instead runs one task of every node, each
dresses) and optionally cgroups, enabling direct commu- time the user adds a node to the swarm the orchestra-
nication between them. Highly coupled containers (mul- tor creates a task and the scheduler assigns the task to
tiple micro-services composing the same application) typ- the new node [32]. Concerning security, Docker Swarm
ically run in the same pod. Pods are the base entity of uses the swarm mode PKI. The manager node generates
the Kubernetes orchestrator, just as VM are for classical a new root CA which are used to secure communication
cloud infrastructures. Pods are automatically instantiated with other nodes that join the swarm. Each time a node
and placed on VMs in the cluster, according to redun- joins the swarm, the manager issues a certificate to the
dancy and availability constraints defined by “replication node [32].
controllers”. These replication controllers are themselves
part of “services”: entities that define the global parame- Table 2: Correspondence between Amazon ECS, Kubernetes and
Docker Swarm main components
ters of an application (external port mappings, etc.). All
nodes in a cluster run a daemon (kubelet) that controls
Docker
the local Docker daemon, and a central node performs the Amazon ECS Kubernetes
Swarm
orchestration. Cluster administration is performed via the
Container
kubectl command, and a web interface is expected soon. Node Node
instance (VM)
Kubernetes installation is native in Google Container
ECS agent Kubelet Manager Swarm
Engine, which automatically creates the VMs of the clus-
Task Pod Task
ter. Users can only chose a template for their VMs.
kubectl commands can be run from any machine with cre- Replication
Service N. A.
dentials to access the API on the central node. We experi- controller
mented this setup, choosing the template “n1-standard-1” Task definition Service Service
for the VMs. Installation is also possible on a number of Cluster Cluster Swarm
other commercial platforms [27] (including Amazon EC2)
via distribution and platform-specific scripts. Installation The aforementioned Cloud Provider approaches are sim-
from scratch on a custom platform is also possible. ilar and their orchestrators have corresponding main com-
Microsoft, instead, provides support for Docker both ponents (Table 2). The main differences lie between Tasks
with Azure Container Instances, and with Azure Container and Pods. Indeed, while tasks are groups of containers
Services (AKS). The former is a solution for any scenario that are launched together on the same host, the Ku-
that can operate in a single isolated container, including bernetes pod approach differs from Docker’s micro-service
simple applications and build jobs, while the latter is a so- approach since containers of a same pod share some re-
lution for a full container orchestration, including service sources. A pod is closer to a VM than to a container from
discovery across multiple containers, automatic scaling, a functional point of view, albeit with no kernel. Another
and coordinated application upgrades. Azure Container difference concerns the scaling of the services. In fact,
Instances allows a user to download or build a container Docker Swarm uses Docker Compose to scale an applica-
image. These images can be pushed in an Azure-based pri- tion [33] — being Docker Compose a tool for defining and
vate registry called Azure Container Registry. Users can running multi-container Docker applications [30].
interact with both the images using the Docker CLI tools,
and with containers using the Azure CLI [8]. AKS allows
to rapidly distribute Docker Swarm, DC/OS, and Kuber- 7. Docker vulnerability-oriented analysis
netes clusters [9]. AKS has the sole task of installing and
deploying the cluster. The orchestrators, in turn, have For each of the three typical Docker use-cases detailed in
the goal of managing the containers and services itself. the previous section, the chosen approach is to define first
A swarm represents a cluster of nodes that can be either an adversary model, and then to perform a vulnerability-
physical or virtual machines. There are two types of nodes: oriented security analysis [59].
manager and worker nodes. The manager nodes maintain
the state of the swarm, while the worker ones have the 7.1. Adversary model
burden to execute containers [32]. An application image
can be deployed by creating a service. When a user de- Given the ecosystem and use-cases description, we con-
ploys the service to the swarm, the swarm manager has sider two main categories of adversaries, i.e., direct and
the responsibility to schedule it as one o more tasks that indirect.
run independently of each other on nodes in the swarm. A direct adversary is able to sniff, block, inject, or mod-
A task is the atomic unit of scheduling within a swarm ify network and system communications. She targets di-
which is instantiated inside a container. Docker Swarm rectly the production machines. Locally or remotely, she
provides two types of service deployments: replicated and can compromise:
10
 • in-production containers (e.g., from an Internet fac- We discuss below these five categories, highlighting the
ing container service, she gains root privileges on the limits of the protections offered by Docker. We assume
related container; from a compromised container, she minimal configuration (at least the default config) is ap-
makes a DoS on co-located containers, i.e., containers plied.
on the same host OS);

• in-production host OS (e.g., from a compromised con- 7.3. Insecure configuration

tainer, she gains access to critical host OS files, i.e., a
container’s escape); Docker’s default configuration is relatively secure as it
provides isolation between containers and restricts the
• in-production Docker daemons (e.g., from a compro- containers’ access to the host. A container is placed in
mised host OS, she lowers the default security param- its own namespaces and own cgroup, and only owns the
eters to launch Docker containers); following capabilities: CAP CHOWN, CAP DAC OVERRIDE,
CAP FSETID, CAP FOWNER, CAP MKNOD, CAP NET RAW,
• the production network (e.g., from a compromised CAP SETGID, CAP SETUID, CAP SETFCAP, CAP SETPCAP,
host OS, she redirects network traffic). CAP NET BIND SERVICE, CAP SYS CHROOT, CAP KILL
An indirect adversary has the same capabilities of a di- and CAP AUDIT WRITE.
rect one, but she leverages the Docker ecosystem (e.g., the
code and images repositories) to reach the production en- Vulnerabilities. The use of some options, either given to
vironment. the Docker daemon on startup, or given to the command
Depending on the attack phase, we identified the fol- launching a container, can provide containers an extended
lowing targets: containers, host OS, co-located containers, access to the host. We have, for instance:
code repositories, images repositories, management net-
work. • Mounting of sensitive host directories into containers
To subvert a dockerized environment, we consider here
a subset of all the potential attack vectors, i.e., Docker • TLS configuration of remote image registries
containers, code repositories, and images repositories. We
consider primarily these attack vectors as they are associ-
• Permissions on the Docker control socket
ated with services and interfaces publicly available. Other
attack vectors may include host OS, management network
or physical access to systems. • Cgroups activation (disabled by default)

• Options directly providing to containers an ex-

7.2. Vulnerabilities identification
tended access to the host (--net=host, --uts=host,
In this section we analyze separately the main compo- --privileged, additional capabilities)
nents of the Docker ecosystem, revealing (part of) their
attack surface.
Following a top-down approach, we identified five cat- Exploitation. For example, the option --uts=host al-
egories of vulnerabilities, each one related to a differ- locates the container in the same UTS namespace of
ent layer of the ecosystem. Typical use-cases (see Sec- the host. This, in turn, allows the container to see
tion 6), already observed vulnerabilities (e.g., CVE [14]), and change the host’s name and domain. The option
and scope of the mitigations (e.g., SELinux, seccomp) en- --cap-add=<CAP> gives to the container the specified ca-
riched this iterative process. pability, thus making it potentially more harmful to the
host. With --cap-add=SYS ADMIN, a container can, for
These levels are classified from the most remote to the
instance, remount /proc and /sys sub-directories in read-
most local one, relatively to a production system hosting
/write mode, and change the host’s kernel parameters,
Docker containers:
leading to potential vulnerabilities, such as data leakage
or denial of service.
• Insecure production system configuration;
Along with these runtime container options, several set-
• Vulnerabilities in the image distribution, verification, tings on the host can pave the way to attacks. Even basic
decompression, storage process; properties can at least trigger denial of service. For in-
stance, with some storage drivers (e.g., AUFS), Docker
• Vulnerabilities inside the images; does not limit containers disk usage. A container with
• Vulnerabilities directly linked to Docker or libcon- a storage volume can fill this volume and affect other
tainer; and, containers on the same host, or even the host itself if
the Docker storage, located at /var/lib/docker, is not
• Vulnerabilities of the Linux kernel. mounted on a separate partition.
11
Mitigation. In order to limit these harmful options which service (zipbomb-like attack). Then, since images are ex-
can lead to have the host being accessed by the container, tracted on the host file-system, path traversals have been
the Center for Internet Security realized a Docker Bench- possible in the past (CVE-2014-9356 [13], fixed in Docker
mark [11]. It provides two lists of options: the ones that 1.3.3). Exploitation of this vulnerability made the uncom-
should be used and the ones that should not be used when pression of the images (which is performed as root) follow
running containers as isolated applications with Docker. absolute symlinks on the host, making possible to replace
These options are sorted in six categories: Host configura- binaries on the host with binaries from the image. Other
tion, Docker daemon configuration, Docker daemon con- possible attacks include code injection in images or replay
figuration files, Container images and build file, Container of old images containing known vulnerabilities.
runtime, and Docker security operations. They include
the ones mentioned above, along with other host config-
uration, hardening configuration, file permissions on the Mitigation. Before release 1.8, the only protection was
host, and TLS configuration for Docker registries and the the use of TLS on the connection to the registry, which
control socket. could be disabled. With version 1.8, Docker introduced
A Docker host running containers that fulfill both the Content Trust [16], an architecture for signing images
good practices [15] and the CIS recommendations [11], and the same way packages are signed with package man-
that further embed a single userspace application, should agers. This raises two issues. First, Content Trust —and
not need any of the options cited beforehand. Using these so image signature check— can be disabled passing the
options one can break the isolation property. Hence, these --disable-content-trust option to the Docker daemon.
options should be used only with trusted containers, re- This looks convenient for a private registry on a local net-
ducing the container to an application packaging tool on work, but constitutes a security vulnerability. Then, the
the production host, and not to an isolation tool. image signature process requires to trust the developers,
which is only possible by unifying the image signature.
7.4. Vulnerabilities in the image distribution process Moreover, this solution does not scale with thousands of
developers signing their repositories with their own key.
The distribution of images through the Docker Hub and Beyond the technical challenge, this is a problem of trust
other registries is a source of vulnerabilities in Docker, and scale.
since the code within these images will be executed on
the host. We first discuss vulnerabilities and attacks on
the Docker Hub and other registries. Then, we study vul- 7.4.2. Automated deployment pipeline vulnerabilities
nerabilities that are more specific to Docker, such as vul- Vulnerabilities. Automated builds and webhooks pro-
nerabilities in the extraction process, and related to the posed by the Docker hub are a key element in this dis-
automated build chain. tribution process. They lead to a pipeline where each el-
ement has full access to the code that will end up in pro-
7.4.1. Docker as a package manager duction. Each element is also increasingly hosted in the
Vulnerabilities. The architecture of the Docker Hub is sim- cloud. For instance, to automate this deployment, Docker
ilar to a package repository, with the Docker daemon act- proposes automated builds on the Docker Hub, triggered
ing as a package manager on the host. Therefore it is vul- by an event from an external code repository (GitHub,
nerable to the same vulnerabilities of package managers. BitBucket, etc.) — Fig. 4, step 2. Docker then proposes
These vulnerabilities include processing, storage and un- to send an HTTP request to a Docker host reachable on
compression of potentially untrusted code, performed by the Internet to notify it that a new image is available; this
the Docker daemon with root privileges. This code can event triggers an image pull and the container restarts on
be either tampered at the source (malicious image) or the new image (Docker hooks [17]) — Fig. 4, steps 9 and
during the transfer (for instance as a consequence of the 10. With this deployment pipeline, a commit on GitHub
--insecure-registry option given to the Docker dae- (Fig. 4, step 1) will trigger a build of a new image (Fig. 4,
mon, that makes possible a Man-in-the-Middle attack be- step 2); this image will be automatically launched it in
tween the registry and the host). production (Fig. 4, steps 9 and 10). Optional test steps
can be added before production, themselves potentially
Exploitation. Attacks on package managers are possi- being hosted at another provider. In this last case, the
ble [39] if an attacker controls a part of the network be- Docker Hub makes a first call to a test machine (Fig. 4,
tween the Docker host and the repository. A successful steps 3 and 5), that will then pull the image, run the tests,
attack would allow her to make her image downloaded and send the results to the Docker Hub using a callback
on docker hosts. This leads to compromised images that URL (Fig. 4, steps 4 and 6). The build process itself often
can exploit vulnerabilities in the extraction process. First, downloads dependencies from other third-parties reposito-
since images are compressed, a specifically crafted image ries (Fig. 4, steps 7 and 8), sometimes over an unsecure
containing a huge file filled with gibberish data (e.g., zeros) channel (that could be tampered with). The whole code
would at least fill the host storage device causing denial of pipeline is exposed in Fig. 4.
12
 #!/bin/bash
while [ 1 -eq 1 ]
do
status=‘docker pull docker_hub_acc/dockerhook-auto \
| grep "Image is up to date"‘
if [ "$status" = "" ]
then # Updating and restarting container
docker ps | grep docker_hub_acc/dockerhook-auto \
| awk ’{print $1 }’ | xargs docker stop
docker rm dockerhook
docker run -d -p 82:80 --name dockerhook \
docker_hub_acc/dockerhook-auto
fi
sleep 5
done

Figure 5: Script monitoring the remote repository and updating the

container if a new version is available

minutes. Compromise could also happen at the Docker

Hub account level, with the same consequences. Account
hijacking is not a new problem, but it should be an increas-
ing concern with the multiplication of accounts at differ-
ent providers. With source code tampered at the victim
Figure 4: Automated deployment setup in the public cloud using machine, TLS is useless. Actually, the tampered code is
GitHub, the Docker Hub, external test machines and repositories
from where code is downloaded during build process.
“securely” distributed over TLS to the various reposito-
ries. Furthermore, with TLS, IDS and IPS monitoring
solutions are blind — unless legitimate man-in-the-middle
Exploitation. In this architecture, compromise approaches setups are done.
include account hijacking, tampering with network com- Moreover, while code path is usually (and always with
munications (depending on the use of TLS), and insider at- Docker) secured using TLS communications, it is not the
tacks. This setup adds several external intermediary steps case of API calls that trigger builds and callbacks. Tam-
to the code path, each of them having its own authen- pering with these data can lead to erroneous test results,
tication and attack surface, overall increasing the global unwanted restarts of containers, etc.. Additionally, such
attack surface. a setup is not compatible with the Content Trust scheme,
For instance, we had the intuition that a compromised since code is processed by external entities between the de-
GitHub account could lead to the execution of malicious veloper and the production environment. Content Trust
code on a large set of production machines within min- provides an environment in which a single entity is trusted
utes. We therefore tested a scenario including a Docker (the person or organization that signed the images) while
Hub account, a GitHub account, a development machine in the present case trust is split over several external en-
and a production machine. The assumption was that the tities, each of them being capable of compromising the
adversary will use the Docker ecosystem to put in pro- images.
duction a backdoored Docker container. More precisely,
we assumed that the adversary had successfully compro- 7.5. Vulnerabilities inside the images
mised some code on the code repository (for instance, via The code available for download on the Docker Hub
a successful phishing attack). (used to build images) is directly exposed to attackers
Due to network restrictions (corporate proxy) our when in production.
servers could not be reached by webhooks, so we wrote a
script to monitor our repository on the Docker Hub as well Vulnerabilities. in [45] it has been showed from crawling
as downloads of new images (Fig. 5). Our initial intuition the Docker Hub that 36% of official images contain high-
was confirmed: adversary’s code was put in production 5 priority CVE vulnerabilities, and 64% contain medium or
minutes and 30s after the adversary’s commit on GitHub. high-priority vulnerabilities. These figures lower to 23%
This attack is particularly dreadful, since it scales to an and 47% respectively for images tagged “latest”. Although
arbitrary number of machines watching the same Docker these images are the most downloaded on the Docker Hub,
Hub repository. they contain a significantly high amount of vulnerabili-
Note that while compromising a code repository is in- ties, including some recent well known vulnerabilities (e.g.,
dependent of Docker, automatically pushing it in produc- shellshock and heartbleed).
tion dramatically increases the number of compromised The DevOps movement, promoted by Docker, lets devel-
machines, even if the malicious code is removed within opers package themselves their applications, thus mixing
13
the development and production environments hence pos- version 1.12.3. Since container processes often run with
sibly introducing vulnerabilities. Development versions of PID 0 (i.e., root privileges), they have read and write ac-
packages or dev tools can remain in the final version of the cess on the whole host file-system when they escape. Thus,
Docker image, increasing its attack surface (e.g., a debug- they are allowed to overwrite host binaries, which leads to
ging tool installed in the image). a delayed arbitrary code execution with root privileges.
Then, the provided images often contain outdated ver-
sions of packages, either because their base image (e.g., Exploitation. Beyond the kernel namespaces, cgroups,
Ubuntu or Debian) is old or because their build process Docker dropping capabilities and mount restrictions,
pulls outdated code from some remote repository. The Mandatory Access Control (MAC) can enforce constraints
multiplication of image builds —virtually one for each in case the normal execution flow is not respected. This
commit in a project— leads to a persistence of outdated approach is visible in the docker-default Apparmor pol-
images still available on the repositories, while fast devel- icy. However, there is room for improvements in the MAC
opment cycles generally focus on latest versions. profiles for containers. In particular, Apparmor profiles
normally behave as whitelists [3], explicitly declaring the
Exploitation. Exploitation of such vulnerabilities is rele- resources any process can access, while denying any other
vant in a context where the attack comes from outside access when the profile is in enforce mode. However,
(i.e., not a malicious image). Classical application vulner- the docker-default profile installed with the docker.io
abilities exploitation methods are possible, provided that package gives containers full access to network devices, file-
the container exposes an entry point (network port, input systems along with a full set of capabilities, and contains
data, etc.). Additionally, images built from external code just a small list of deny directives, consisting de facto in
repositories (i.e., images that pull data from some repos- a blacklist.
itory during the build process —Online code on Fig. 4—
as stated in their Dockerfile) are dependent on this repos- 7.7. Vulnerabilities of the Linux kernel
itory and on the (in)security of the connection used to
Since containers run on the same kernel of the host,
fetch these data. These repositories, not always official,
they are vulnerable to kernel exploits. An exploit giving
are another entry point for code injection.
full root privileges into a container can allow an attacker
to break out this container and compromise the host (trig-
Mitigation. Both Docker Hub and Docker Cloud make use
gering for instance isolation and integrity breach, as well
of the Docker Security Scanning. Users can scan images
as data exposure).
in private repositories to verify that they are free from
kwown security vulnerabilities. This feature is available as
a free preview for private repository subscribers for a lim- 8. Discussion
ited time. The scan traverses each layer of the image, iden-
tifying the software components and indexing their SHAs. 8.1. Vulnerability assessment
These SHAs are compared against the CVE database in We conducted an assessment of the severity of the ex-
order to obtain information about the well-known security plained vulnerabilities (Table 3) according to each use-
vulnerabilities [22]. The whole scan phase takes from 1 to case. This is coherent with the choice we made to analyze
24 hours, depending on the size of the evaluating images. the Docker ecosystem and typical use-cases rather than
The support provided is limited due to both the availabil- focusing on a specific use-case with a specific application.
ity only for private repositories and the cost of the service. This is also consistent with the NIST methodology that
Moreover, if a vulnerability is not part of the database the defines the context as a dimension that has to be con-
scan cannot reveal it, making the service unresponsive to sidered when performing a vulnerability assessment [59].
new attacks. Therefore, we defined three use-cases to base our compar-
ison upon and we also proved experimentally some of the
7.6. Vulnerabilities directly linked to Docker or libcon- highlighted vulnerabilities.
tainer Our assessment is exclusively focused on the difference
Vulnerabilities. Vulnerabilities found into Docker and lib- between use-cases, all other dimensions (i.e., threats and
container [14] mostly concern file-system isolation: chroot remediations) being equal. As a general comment, the
escapes (CVE-2014-9357, CVE-2015-3627), path traver- wide-spread use-case (i.e., casting containers as VM) ex-
sals (CVE-2014-6407, CVE-2014-9356, CVE-2014-9358), poses vulnerabilities more than the other use-cases. More-
access to special file systems on the host (CVE-2015- over, we can see that, whatever the considered use-cases,
3630, CVE-2016-8867, CVE-2016-8887), container esca- the kernel vulnerabilities are of a similar severity level,
lation (CVE-2014-6408), and privilege escalation (CVE- as well as the vulnerabilities directly linked to Docker.
2016-3697). Most of these specific vulnerabilities are all We believe that this analysis of the different layers of the
patched as of Docker version 1.6.1. Further, CVE-2016- Docker ecosystem provides a valuable vulnerability assess-
3697 is patched as of Docker version 1.11.0 while CVE- ment state of the art and a sound basis for the research
2016-3697 and CVE-2016-8867 are patched with Docker community upcoming contributions.
14
 Table 3: Relative assessment scale of vulnerabilities severity on the three developed usages.

Wide-spread use-case
Vulnerability Docker recommended Cloud Provider CaaS
(e.g., casting
categories use-case use-case
containers as VM)
Moderate.
Docker’s default High
configuration on local CIS benchmark on EC2
systems is relatively Very high by default score 62% of
Insecure configuration secure — see Section 7.3. Very likely insecure compliance. Containers
Lowering of security configuration. in pods sharing the same
configuration possible by NET namespace with
the sysadmin or Kubernetes.
containers placement.
Very high
Usage promoted
Vulnerabilities in the High
extensively be the Moderate
image distribution, Automation at all layers
DevOps approach. Containers used as VMs,
verification, to bring shorter
Automation at all layers followed by less
decompression and development cycles and
to bring shorter continuous delivery
storage process continuous delivery.
development cycles and
continuous delivery.
Very high Moderate
Very likely usage of Depending on what
Moderate heavyweight Linux images and where they
Vulnerabilities inside
By default exposing a distribution images with are retrieved from: both
the images
limited attack surface. an attack surface bigger micro-server and VM like
than micro-services- usages are possibly used
oriented images. here.
Vulnerabilities
Similar level across N. A. N. A.
directly linked to
the use-cases
Docker or libcontainer
Vulnerabilities in the Similar level across
N. A. N. A.
kernel the use-cases

8.2. Multi-tenant implementation

Container execution in PaaS providers data-centers is
becoming a standard for cloud applications [7] [46]. En-
suring isolation is of paramount importance in such multi-
tenant installations where users can run their own code
in containers. We showed in Section 6.3 that main pub-
lic cloud providers run these containers inside VM, and
allocate a VM to a single user, creating a vertical multi-
tenancy. These VMs are sometimes themselves running in
containers (e.g., Google Container Engine [46]) — Fig. 6.
Users may also delegate accounts to other users in their
cluster, creating an horizontal multi-tenancy, where con-
tainers belonging to different users run concurrently in the
same VM. For instance, Kubernetes allows creating user
accounts within a cluster, each user being able to run con-
tainers. As illustrated in Fig. 6, the security profiles (e.g.,
SELinux and Apparmor profiles) are stacked at multiple
layers. Therefore, the configuration of these security pro-
files may be challenging. In particular, enforcing cumu-
Figure 6: Containers integration in a multi-tenant cloud system. lative and independently managed security profiles could
There can be up to three different tenants vertically, and for each lead to a situation where legitimate actions could be pre-
vertical layer an arbitrary number of tenants horizontally.
15
vented from executing. This can become a complex task, vulnerabilities arisen from the automated construction of
since even with basic Apparmor profile, we observed un- images triggered by events from external code repository,
expected behaviours, as described below. such as Docker Hub and BitBucket), as well as a taxon-
omy that can be used by other scientists and practitioners
to evolve the mapping between solutions and the related
#!/bin/bash vulnerabilities contributing to the identification of possible
mount -o remount,rw /proc/sys
mount -o remount,rw /proc/sysrq-trigger
countermeasures.
echo 1 > /proc/sys/kernel/sysrq
echo p > /proc/sysrq-trigger 8.4. Alternatives to Docker
In parallel to containers, Unikernels have been around
Figure 7: Script assessing effective application of Apparmor restric- for a few years. Although they are not used in produc-
tions tion yet, they address the isolation issue by embedding
their own kernel, specifically optimized for one application.
A script (Fig. 7) was run in a Docker container trying They achieve performance close to or even better than
to perform actions prohibited by the apparmor-default containers, and their very fast boot could allow launching
profile while it was enforced. This container was run with them on the fly to serve a specific request. Latest tech-
the --cap-add=SYS ADMIN option, so that it could per- nology developments promote unikernels to be a serious
form the mount command. We ran our tests on two ma- concurrent to containers [54] [53] for the coming years.
chines: a Debian 8 (kernel 3.16) with the Docker package
from the distribution (version 1.6.2) and an Ubuntu 14.04
9. Conclusion
(kernel 3.19) with Docker installed from get.docker.com
(version 1.8.3). The default Apparmor profiles for In this paper, we performed a review of the components
both distributions forbid mounts and write access to of the whole Docker ecosystem—the containers, the code
/proc/sys/kernel/sysrq and /proc/sysrq-trigger, so delivery, and related orchestration. Leveraging an exten-
that even with CAP SYS ADMIN none of these com- sive literature review, coupled with a security-driven clas-
mands should succeed. While on Ubuntu the commands sification, we have identified key elements to assess the
were blocked, the mounts were successfully performed on security of each component. In particular, we highlighted
the Debian 8, even though the profile contained en explicit some new classes of vulnerabilities. To substantiate our
“deny mount”. findings, we performed some experiments to demonstrate
This example shows that, even with a regular installa- how tangible were the security risks. We showed that the
tion from repositories and a rudimentary script, the Ap- usual comparison “VM vs. containers” is inappropriate
parmor default profile for Docker may be applied differ- since the use cases are different and so is the underlying
ently. This situation can only worsen when several layers architecture.
of containers and hardening are nested, as illustrated in We also showed that from a local point of view, many
Fig. 6. vulnerabilities of Docker are due to casting containers as
Additionally, this architecture does not replace VM, so VM. From the point of view of the ecosystem, the multipli-
the rapidity of execution of containers is not exploited as it cation of external intermediaries, providing code that will
could be. Code execution paths of containers (left arrow end up in production, widely increases the attack surface.
on Fig. 6) are even longer than with a single VM, since Further, we discussed the current usage of orchestrators,
they add two Docker processes, with their libraries and and pointed out that these orchestrators could be a means
the associated hardening. of limiting misuse of Docker — leading to host and con-
tainers weak isolation. In particular, enforcing isolation
8.3. Synoptic survey could be achieved introducing higher levels of abstraction
(tasks, replication controllers, remote persistent storage,
According to the categories introduced above, we map in
etc.) that completely remove host dependence, enabling
Table 4 the contributions of the most representative work
better isolation. We are currently working on the analysis
on containers, as well as our own.
of the orchestrators security.
The topic of containers has been addressed in the lit-
erature from different perspectives. Some work make
a comparison with virtual machines, either from a per-
formance point of view [43, 56, 44] or from a security
one [52]. Other work evaluate the security aspects of
containers [38, 58, 35, 55, 57] or propose defenses related
to specific attacks [40, 47]. The analysis of Docker vul-
nerabilities (generic or specific) are dealt with in various
work [40, 45, 61, 52, 57] but in this paper we introduce
new elements (e.g., the analysis and exploitation of the
16
 Table 4: Synoptic survey of the major current contributions in the container domain

Use-cases
Container and
Security aspects Defense against Defense against Vulnerability driven
virtualization
of containers DoS attacks Escape attacks analysis vulnerability
comparison
analysis
[43] X
[56] X
[44] X
[38] X
[58] X
[35] X
[55] X
[40] X X
[47] X X
[45] X
[61] X
[52] X X X
[57] X X X
This work X X X X

References [19] Docker hub official repositories, Last checked January 2018.
https://docs.docker.com/docker-hub/official_repos.
[1] Containers: Real adoption and use cases in 2017. [20] Docker image specification, Last checked January 2018.
http://en.community.dell.com/techcenter/cloud/m/dell_ https://github.com/docker/docker/blob/master/image/
cloud_resources/20443801. spec/v1.md.
[2] Notes from a container, October 2007. https://lwn.net/ [21] Docker overview, Last checked January 2018. https://www.
Articles/256389. docker.com/company.
[3] Novell apparmor administration guide, September 2007. [22] Docker security scanning, Last checked January 2018. https:
https://www.suse.com/documentation/apparmor/pdfdoc/ //docs.docker.com/docker-cloud/builds/image-scan.
book_apparmor21_admin/book_apparmor21_admin.pdf. [23] Docker store, Last checked January 2018. https://docs.
[4] Docker and ssh, June 2014. https://blog.docker.com/2014/ docker.com/docker-store.
06/why-you-dont-need-to-run-sshd-in-docker. [24] Docker use-cases, Last checked January
[5] docker-default apparmor profile, June 2014. https:// 2018. https://www.airpair.com/docker/posts/
wikitech.wikimedia.org/wiki/Docker/apparmor. 8-proven-real-world-ways-to-use-docker.
[6] Containers are not vms, March 2016. https://blog.docker. [25] Dockerfile reference, Last checked January 2018. https://docs.
com/2016/03/containers-are-not-vms/. docker.com/engine/reference/builder.
[7] Amazon ec2 container service reference, Last checked Jan- [26] Google compute engine reference, Last checked January 2018.
uary 2018. http://docs.aws.amazon.com/AmazonECS/latest/ https://cloud.google.com/compute/docs/.
developerguide/ECS_instances.html. [27] Kubernetes installation advices, Last checked January 2018.
[8] Azure container instances, Last checked January 2018. https: https://kubernetes.io/docs/setup/pick-right-solution/.
//docs.microsoft.com/en-us/azure/container-instances/. [28] Kubernetes orchestrator, Last checked January 2018. http:
[9] Azure container services, Last checked January 2018. https: //kubernetes.io/.
//docs.microsoft.com/en-us/azure/container-service/. [29] Linux kernel namespaces man page, Last checked January 2018.
[10] Boot2docker project, Last checked January 2018. http:// http://man7.org/linux/man-pages/man7/namespaces.7.html.
boot2docker.io/. [30] Overview of docker compose, Last checked January 2018.
[11] Cis docker benchmark. Tech. rep., Center for Internet Security, https://docs.docker.com/compose/overview/.
January 2018. [31] Rancheros project, Last checked January 2018. http://
[12] Coreos project, Last checked January 2018. https://coreos. rancher.com/docs/os/v1.1/en/.
com/docs/. [32] Swarm mode, Last checked January 2018. https://docs.
[13] Cve-2014-9356, Last checked January 2018. https:// docker.com/engine/swarm/how-swarm-mode-works/nodes/.
security-tracker.debian.org/tracker/CVE-2014-9356. [33] Use compose with swarm, Last checked January 2018. https:
[14] Cve vulnerability statistics on docker, Last checked Jan- //docs.docker.com/compose/swarm/.
uary 2018. http://www.cvedetails.com/product/28125/ [34] Xen wiki page about unikernels, Last checked January 2018.
Docker-Docker.html. http://wiki.xenproject.org/wiki/Unikernels.
[15] Docker best practices, Last checked January 2018. [35] Bacis, E., Mutti, S., Capelli, S., and Paraboschi, S. Dock-
https://docs.docker.com/engine/userguide/eng-image/ erpolicymodules: mandatory access control for docker contain-
dockerfile_best-practices. ers. In Communications and Network Security (CNS), 2015
[16] Docker content trust, official documentation, Last checked IEEE Conference on (2015), IEEE, pp. 749–750.
January 2018. https://docs.docker.com/engine/security/ [36] Biederman, E. Multiple instances of the global linux
trust/content_trust. namespaces. In Proceedings of the 2006 Linux Sym-
[17] Docker hub: Automated builds and webhooks, Last checked posium (2006). https://www.kernel.org/doc/ols/2006/
January 2018. https://docs.docker.com/docker-hub/builds. ols2006v1-pages-101-112.pdf.
[18] Docker hub images, Last checked January 2018. https://hub.
docker.com/explore.

17
[37] Briggs, I., Day, M., Guo, Y., Marheine, P., and Eide, E. A of the 12th USENIX Conference on Networked Systems De-
performance evaluation of unikernels. Tech. rep., 2014. sign and Implementation (Berkeley, CA, USA, 2015), NSDI’15,
[38] Bui, T. Analysis of Docker Security, 2015. arXiv:1501.02967v1. USENIX Association, pp. 559–573.
[39] Cappos, J., Samuel, J., Baker, S. M., and Hartman, J. H. A [54] Madhavapeddy, A., Mortier, R., Rotsos, C., Scott, D.,
look in the mirror: attacks on package managers. In Proceedings Singh, B., Gazagnaire, T., Smith, S., Hand, S., and
of the 2008 ACM Conference on Computer and Communica- Crowcroft, J. Unikernels: Library operating systems for the
tions Security, CCS 2008, Alexandria, Virginia, USA, October cloud. vol. 48, ACM, pp. 461–472.
27-31, 2008, pp. 565–574. [55] Miller, A., and Chen, L. Securing your containers - an
[40] Chelladhurai, J., Chelliah, P. R., and Kumar, S. A. Se- exercise in secure high performance virtual containers. In
curing docker containers from denial of service (dos) attacks. In Proceedings of the International Conference on Security and
Services Computing (SCC), 2016 IEEE International Confer- Management (SAM) (2012), The Steering Committee of The
ence on (2016), IEEE, pp. 856–859. World Congress in Computer Science, Computer Engineer-
[41] Combe, T., Martin, A., and Di Pietro, R. To docker or not ing and Applied Computing (WorldComp), p. 1. http://
to docker: A security perspective. IEEE Cloud Computing 3, 5 worldcomp-proceedings.com/proc/p2012/SAM9702.pdf.
(2016), 54–62. [56] Morabito, R., Kjallman, J., and Komu, M. Hypervisors vs.
[42] Di Pietro, R., and Lombardi, F. Security for Cloud Comput- lightweight virtualization: A performance comparison. In Pro-
ing. Artec House, Boston, 2015. ISBN 978-1-60807-989-6. ceedings of the 2015 IEEE International Conference on Cloud
[43] Dua, R., Raja, A., and Kakadia, D. Virtualization vs con- Engineering (2015), pp. 386–393.
tainerization to support paas. In Proceedings of the 2014 IEEE [57] Mouat, A. Docker security using containers safely in produc-
International Conference on Cloud Engineering (IC2E) (March tion, 2015.
2014), pp. 610–614. [58] Reshetova, E., Karhunen, J., Nyman, T., and Asokan, N.
[44] Felter, W., Ferreira, A., Rajamony, R., and Rubio, Security of os-level virtualization technologies: Technical re-
J. An updated performance comparison of virtual machines port. CoRR abs/1407.4245 (2014).
and linux containers. Tech. rep., IBM Research Report, [59] Ross, R. S. Guide for conducting risk assessments (nist sp-800-
July 2014. http://www.cs.nyu.edu/courses/fall14/CSCI-GA. 30rev1). The National Institute of Standards and Technology
3033-010/vmVcontainers.pdf. (NIST), Gaithersburg (2012).
[45] Gummaraju, J., Desikan, T., and Turner, Y. Over 30% [60] Samuel, J., Mathewson, N., Cappos, J., and Dingledine, R.
of official images in docker hub contain high priority security Survivable key compromise in software update systems. In Pro-
vulnerabilities. Tech. rep., BanyanOps, May 2015. ceedings of the 17th ACM Conference on Computer and Com-
[46] Intel. Linux* containers streamline virtualization and comple- munications Security (New York, NY, USA, 2010), CCS ’10,
ment hypervisor-based virtual machines. ACM, pp. 61–72.
[47] Jian, Z., and Chen, L. A defense method against docker escape [61] Shu, R., Gu, X., and Enck, W. A study of security vulner-
attack. In Proceedings of the 2017 International Conference on abilities on docker hub. In Proceedings of the Seventh ACM
Cryptography, Security and Privacy (2017), ACM, pp. 142–146. on Conference on Data and Application Security and Privacy
[48] Kamp, P.-H., and Watson, R. N. M. Jails: Confining the (2017), ACM, pp. 269–280.
omnipotent root. In Proceedings of the 2nd International [62] Soltesz, S., Pötzl, H., Fiuczynski, M. E., Bavier, A., and
System Administration and Networking Conference (SANE) Peterson, L. Container-based operating system virtualization:
(May 2010). http://therbelot.free.fr/Install_FreeBSD/ A scalable, high-performance alternative to hypervisors. In Pro-
jail/jail.pdf. ceedings of the 2Nd ACM SIGOPS/EuroSys European Confer-
[49] Killalea, T. The hidden dividends of microservices. Commu- ence on Computer Systems 2007 (New York, NY, USA, 2007),
nications of the ACM 59, 8 (2016), 42–45. EuroSys ’07, ACM, pp. 275–287.
[50] Lombardi, F., and Di Pietro, R. Secure virtualization for [63] Wright, C. P., and Zadok, E. Kernel korner: Unionfs: Bring-
cloud computing. Journal of Network and Computer Applica- ing filesystems together. Linux J. 2004, 128 (Dec. 2004), 8–.
tions 34, 4 (2011), 1113–1122. [64] Xavier, M. G., Neves, M. V., Rossi, F. D., Ferreto, T. C.,
[51] Lombardi, F., and Di Pietro, R. Virtualization and cloud Lange, T., and De Rose, C. A. F. Performance evaluation of
security: Benefits, caveats, and future developments. In Cloud container-based virtualization for high performance computing
Computing, Z. Mahmood, Ed., Computer Communications and environments. In Proceedings of the 2013 21st Euromicro In-
Networks. Springer International Publishing, 2014, pp. 237–255. ternational Conference on Parallel, Distributed, and Network-
[52] Lu, T., and Chen, J. Research of penetration testing technol- Based Processing (Washington, DC, USA, 2013), PDP ’13,
ogy in docker environment. IEEE Computer Society, pp. 233–240.
[53] Madhavapeddy, A., Leonard, T., Skjegstad, M., Gazag- [65] Zheng, C., and Thain, D. Integrating containers into work-
naire, T., Sheets, D., Scott, D., Mortier, R., Chaudhry, flows: A case study using makeflow, work queue, and docker.
A., Singh, B., Ludlam, J., Crowcroft, J., and Leslie, I. In Proceedings of the 8th International Workshop on Virtual-
Jitsu: Just-in-time summoning of unikernels. In Proceedings ization Technologies in Distributed Computing (New York, NY,
USA, 2015), VTDC ’15, ACM, pp. 31–38.

18

View publication stats