Analysis of Docker Security

Thanh Bui
Aalto University School of Science
thanh.bui@aalto.fi

Abstract alization [19]. However, container-based virtualization also

comes with security concerns.
Over the last few years, the use of virtualization technolo- In this paper, we analyze the security level of Docker
gies has increased dramatically. This makes the demand for [17], a well-known representative of container-based virtu-
efficient and secure virtualization solutions become more ob- alization approach. We consider two areas: (1) the internal
vious. Container-based virtualization and hypervisor-based security of Docker, and (2) how Docker interacts with the
arXiv:1501.02967v1 [cs.CR] 13 Jan 2015

virtualization are two main types of virtualization technolo- security features of the Linux kernel, such as SELinux and
gies that have emerged to the market. Of these two classes, AppArmor, in order to harden the host system. The analysis
container-based virtualization is able to provide a more examined the internal security of Docker based on the level
lightweight and efficient virtual environment, but not without of isolation Docker can provide to its virtual environments.
security concerns. In this paper, we analyze the security level The interaction between Docker and the security features of
of Docker, a well-known representative of container-based the kernel was estimated based on how the features are sup-
approaches. The analysis considers two areas: (1) the inter- ported by Docker. To the best of our knowledge, Docker is a
nal security of Docker, and (2) how Docker interacts with the relatively new technology, and this is one of the first analyses
security features of the Linux kernel, such as SELinux and of this kind that focus on its security aspects.
AppArmor, in order to harden the host system. Furthermore, The paper is structured as follows: Section 2 provides a
the paper also discusses and identifies what could be done high-level view of the two classes of virtualization solutions.
when using Docker to increase its level of security. Section 3 gives an overview of Docker and its underlying
technologies. Section 4 presents our analysis of Docker se-
KEYWORDS: Containers, Docker, Security curity, and then in Section 5, we discuss the security level of
Docker and what could be done to raise its level of security.
The paper concludes with a summary in Section 6.
1 Introduction
The last decade has seen an explosion of development in the 2 Virtualization Approaches
area of virtualization technologies, which allow the partition-
ing of a computer system into multiple isolated virtual en- Most of the virtualization technologies can be classified into
vironments. The technologies offer substantial benefits that two major approaches: container-based virtualization and
have been driving their development rapidly. One of the most hypervisor-based virtualization. The former provides virtu-
common reasons for adopting virtualization technologies is alization at the operating system level, while the latter pro-
server virtualization in data centers. With server virtualiza- vides virtualization at the hardware level. Each of the ap-
tion, an administrator can create one or more virtual system proaches has its own advantages and disadvantages, which
instances on a single server. These virtual systems operate as are described in this section.
real physical servers and can be rented out on a subscription Container-based virtualization is a lightweight virtual-
basis. Amazon EC2, Rackspace, and DreamHost are some ization approach using the host kernel to run multiple vir-
popular instances of such data center service providers. An- tual environments. These virtual environments are often re-
other common use is for desktop virtualization, where one ferred to as containers. Linux-VServer [31], OpenVZ [11],
computer can run several OS instances. Desktop virtualiza- and Linux Container (LXC) [10] are the three main repre-
tion provides support for applications that can run only on a sentatives of this approach. The general architecture of a
specific OS. container-based virtualization solution is illustrated in Fig. 1.
The growth in the use of virtualization technologies pro- Container-based virtualization virtualizes at the operating
motes the demand for a virtualization solution which can system level, thus allowing multiple applications to operate
provide dense, scalable, and secure user environments. A without redundantly running other operating system kernels
large number of virtualization solutions have emerged to on the host. Its containers look like normal processes from
the market. They can be classified into two major classes: outside, which run on top of the kernel shared with the host
container-based virtualization and hypervisor-based virtual- machine. They provide isolated environments with neces-
ization. Of these two classes, container-based virtualization sary resources to execute applications. These resources can
is able to provide a more lightweight and efficient virtual en- be either shared with the host or installed separately inside
vironment. It allows ten times more virtual environments to the container.
run on a physical server compared to hypervisor-based virtu- Hypervisor-based virtualization solutions provide virtu-
Aalto University T-110.5291 Seminar on Network Security Autumn 2014

Figure 3: Architecture of Docker engine

Figure 1: Architecture of Container-based Virtualization

3 Docker Overview
Docker is an open source container technology with the abil-
ity "to build, ship, and run distributed applications" [17]. It
has been used in some popular applications, such as Spotify,
Yelp, and Ebay.
Although container technologies have been around for
more than a decade, Docker - a relatively new candidate -
is currently one of the most successful technologies since
Figure 2: Architecture of Hypervisor-based Virtualization it comes with new abilities that earlier technologies did not
possess. First, it provides interfaces to simply and safely cre-
ate and control containers. Secondly, developers can pack
applications into lightweight Docker containers which can
alization at the hardware level. In contrast to container-based operate on almost anywhere without modification. Further-
virtualization, a hypervisor establishes complete virtual ma- more, Docker can deploy more virtual environments than
chines (VMs) on top of the host operating system (Fig. 2). other technologies can on the same hardware [19]. Last
Each virtual machine comprises of not only an application but not least, Docker cooperates well with third-party tools,
and its dependencies, but also an entire guest OS along with which simplify the management and deployment process of
a separate kernel. There are two classes of hypervisors: the Docker containers. DevOps tools, such as Puppet [13], An-
Type 1 hypervisor, also known as the bare metal hypervisor, sible [1], and Vagrant [16] can integrate with Docker, thus
which works directly on top of the underlying hardware of making Docker containers to be easily deployed to a cloud.
the host, and the Type 2 hypervisor, also known as the hosted Moreover, many orchestration tools, such as Mesos [22],
hypervisor, which works on top of the host operating system Shipyard [15], and Kubernetes [7], also support Docker con-
[26]. Xen [18] is an example of the former, while KVM [25] tainers. These tools provide an abstract layer of resources
is of the latter. Since the Type 1 hypervisor does not include management and scheduling over Docker.
an extra layer of the host OS, it provides better performance
than the Type 2 hypervisor. Docker consists of two major components: Docker engine
and Docker Hub. The former is an open source virtualization
The differences in the architecture bring some benefits to
solution, while the latter is a Software-as-a-Service platform
container-based virtualization over hypervisor-based virtu-
for sharing Docker images. The following sections describe
alization. First, container-based virtualization can provide
in details these two components.
higherer density of virtual environments. Since a container
does not include an entire OS, the size and the required re-
sources to run an application in a container are less than that
of a VM running the same application. As a result, more con- 3.1 Docker Engine
tainers than traditional virtual machines can be deployed on
the same host. Secondly, container-based virtualization also Docker engine is a lightweight and portable packaging tool
offers better performance. This has been demonstrated by [17] which relies on container-based virtualization. There-
experiments in some studies [32, 28, 27, 21]. These studies fore, the architecture of the Docker engine (Fig. 3) is simi-
show that the performance of container-based virtualization lar to that of container-based virtualization in general. The
is better than with hypervisor-based virtualization in most Docker containers run on top of the Docker daemon which
cases, and it is almost as good as native applications. is in charge of executing and managing all of the Docker
However, despite all of the mentioned advantages, containers. The Docker client, which provides an user inter-
container-based virtualization is unable to support a variety face for interacting with containers to Docker users, accepts
of environments in the way hypervisor-based virtualization commands from the users and then sends it to the Docker
does since all the environments of the containers must be of daemon through RESTful APIs. Using this method of com-
the same type as that of the host. For example, Windows munication enables the Docker client to run on the same host
containers cannot be run on top of a Linux host. as the containers, or even on different hosts.
Aalto University T-110.5291 Seminar on Network Security Autumn 2014

ages. Users can also search for published images and down-
load them with the Docker client. Furthermore, users can
verify the authenticity and integrity of the downloaded im-
ages since Docker signed and verified the images when their
owner submitted them to the hub.

4 Docker Security Analysis

Figure 4: Container image Security is one of the major challenges when running ser-
vices in virtual environments, especially in a multi-tenant
cloud system. Virtual machines provided by hypervisor-
based virtualization techniques are claimed to be more se-
Docker Container cure than containers as they add an extra layer of isolation
between the applications and the host. An application run-
Docker used to commoditize LXC to create Docker contain-
ning inside a VM is only able to communicate with the VM
ers. Since version 0.9, Docker has replaced LXC with lib-
kernel, not the host kernel. Consequently, in order for the
container [8] - their own virtualization format - as the default
application to escalate out of a VM, it must bypass the VM
container environment since Docker community desires not
kernel and the hypervisor before it can attack the host ker-
to depend on a third-party package. However, with either
nel. On the other hand, containers can directly communicate
LXC or libcontainer, namespaces, cgroups, union file sys-
with the host kernel, thus allowing an attacker to save a great
tem, and Docker images are still the major underlying tech-
amount of effort when breaking into the host system. This
nologies to implement Docker containers.
raises a security concern over containers.
Docker takes advantages of two Linux features, names-
Docker is also a container-based virtualization technolo-
paces and cgroups, to safely create virtual environment for
gies, thus having the same issue. Our analysis aims to dis-
its containers. The cgroups, or control groups, provide
cover whether Docker provides a safe environment to run
mechanism for accounting and limiting the resources which
applications. The analysis considers two areas: the internal
the processes in each container can access. The namespaces
security of Docker containers and how Docker containers in-
wrap the operating system resources into different instances.
teract with the additional security systems of the kernel.
The use of these instances gives the processes running inside
a container the illusion that they have their own resources.
Currently, Docker uses five namespaces to provide each con- 4.1 Docker Internal Security
tainer with a private view of the underlying host system [23]:
mount, hostname, inter-process communication (IPC), pro- We examine the internal security of Docker based on the
cess identifiers (PID), and network. Each of them works on system and attacker model and security requirements as de-
specific types of system resources. The network namespaces, scribed by Reshetova et al. [29] for comparing a number of
for example, isolate the networking resources, such as IP ad- the OS-level virtualization technologies.
dresses, and IP routing tables, in order to provide each con- The system and attacker model is as follows: A single host
tainer with a separated network stack. machine is running a number of Docker containers c1 ... cn ,
Docker launches its containers from Docker images. A on which a subset C of the containers are compromised and
Docker image is a series of data layers on top of a base im- the attacker has full control over those, but the remaining
age (Fig. 4). Every Docker image starts from a base im- subset of containers C is still under the control of the legit-
age, such as Ubuntu base image or OpenSuse base image. imate users. In this model, the attacker can perform various
When users make changes to a container, instead of directly types of attacks, such as Denial-of-Service and Privilege es-
writing the changes to the image of the container, Docker calation.
adds an additional layer containing the changes to the im- In order to encounter with these attacks, the authors stated
age. For example, if the user installs MySQL to an Ubuntu that an OS-level virtualization solution should satisfy the fol-
image, Docker creates a data layer containing MySQL and lowing requirements: process isolation, filesystem isolation,
then adds to the image. This process makes the image distri- device isolation, IPC isolation, network isolation and limit-
bution process more efficiently since only the update needs ing of resources. The next sections present our analysis on
to be distributed. how Docker fulfills the requirements.
In order to work with multiple layers of an image as it
were a single file system layer, Docker uses a special file Process Isolation
system called Union File System (UnionFS). It allows files
and directories in different file systems to be combined into The main goal of process isolation is to prevent compro-
a single consistent file system. mised containers from using process management interfaces
to interfere with other containers. Docker achieves isolation
3.2 Docker Hub of processes by wrapping the processes running in containers
into namespaces and limiting their permissions and visibility
Docker hub [4] is a central repository of images (both public to processes running in the other containers and the underly-
and private), via which users can share their customized im- ing host.
Aalto University T-110.5291 Seminar on Network Security Autumn 2014

This mechanism operates with the support of the PID Thus, it is crucial to limit the set of device nodes that a con-
namespaces, which isolate the process ID number space of tainer can access.
a container from that of the host. Since PID namespaces are The Device Whitelist Controller feature [3] of cgroups
hierarchical [12], a process can only see the other processes provides means to limit the set of devices that Docker al-
in its own namespace or in its "children" namespaces. As a lows a container to access. It also prevents the processes
consequence, once a new namespace is created and assigned in containers from creating new device nodes. Furthermore,
to a container, the host can observe and affect the processes Docker mounts container images with nodev, meaning that
inside the new PID namespace of the container, but the pro- even if a device node was pre-created inside the image, the
cesses inside the container cannot observe or do anything to processes in the container using the image cannot use it to
the other processes running in the host or in other containers. communicate with the kernel. By default, Docker does not
If the attacker cannot observe other processes, it is harder to give extended privileges to its containers. Therefore, they
attack them. cannot access any devices. However, if the operator exe-
The PID namespaces also allow each container to have its cutes a container as "privileged", Docker grants access to all
own init-like process (PID 1), which causes all the processes devices to the container.
in a namespace to be terminated if it is terminated. This
process assists the administrator in completely shutting down
a container when something suspicious is detected. IPC Isolation

The IPC (inter-process communication) is a set of objects

Filesystem Isolation for exchanging data among processes, such as semaphores,
message queues, and shared memory segments. The pro-
In order to achieve filesystem isolation, the filesystems of cesses running in containers must be restricted so that they
the host and containers must be protected from illegitimate can communicate only via a certain set of IPC resources and
access and modification. are disallowed to interfere with those in other containers and
Docker uses the mount namespaces, also called the filesys- the host machine.
tem namespaces, to isolate the filesystem hierarchy associ- Docker achieves IPC isolation by using the IPC names-
ated with different containers. The mount namespaces pro- paces, which allows the creation of separated IPC names-
vide the processes of each container a different view of the paces. The processes in an IPC namespace cannot read or
filesystem tree and restrict all the mount events occurring write the IPC resources in other IPC namespaces. Docker
inside the container to only have impact inside the con- assigns an IPC namespace to each container, thus preventing
tainer. However, some of the kernel filesystems are not the processes in a container from interfering with those in
namespaced; for example, those under /sys, /proc/sys, other containers.
/proc/sysrq − trigger, /proc/irq, and /proc/bus, and a
Docker container needs to mount them in order to operate.
This causes the issue that a container inherits the view of Network Isolation
these filesystems from the host and are able to access them
directly. Docker limits the threats that a compromised con- Network isolation is important to prevent network-based at-
tainer could make to the host via these filesystems with the tacks, such as Man-in-the-Middle (MitM) and ARP spoof-
two filesystems protection mechanisms: (1) removing the ing. Containers must be configured in such a way that they
write permission to these filesystems from containers and are unable to eavesdrop on or manipulate the network traffic
(2) not allowing any process of a container to remount any of the other containers nor the host.
filesystem within the container [24]. The second mechanism For each container, Docker creates an independent net-
is achieved by removing the CAP _SY S_ADM IN capa- working stack by using network namespaces. Therefore,
bility from containers. each container has its own IP addresses, IP routing tables,
Docker also employs a mechanism called copy-on-write network devices, etc. This allows containers to interact with
file system [24]. As mentioned before, Docker creates con- each other through their respective network interfaces, which
tainers based on file system images, and a container can write is the same as how they interact with external hosts.
content to its own base image. When multiple containers are By default, connectivity between containers as well as to
created on the same image, the copy-on-write file system al- the host machine is provided using Virtual Ethernet bridge
lows each container to write content to its specific file sys- [5] (Fig. 5). With this approach, Docker creates a virtual eth-
tem, thus preventing other containers from discovering the ernet bridge in the host machine, named docker0, that au-
changes occurring inside the container. tomatically forwards packets between its network interfaces.
When Docker creates a new container, it also establishes a
new virtual ethernet interface with a unique name and then
Device Isolation
connects this interface to the bridge. The interface is also
In Unix, the kernel and applications access the hardware connected to the eth0 interface of the container, thus allow-
through device nodes which basically are special files acting ing the container to send packets to the bridge.
as the interfaces to the device drivers. If a container can ac- We note here that the default connectivity model of
cess some important device nodes, such as /dev/mem (the Docker is vulnerable to ARP spoofing and Mac flooding at-
physical memory), /dev/sd∗ (the storage) or /dev/tty (the tacks since the bridge forwards all of its incoming packets
terminal), it can make serious damage on the host system. without any filtering.
Aalto University T-110.5291 Seminar on Network Security Autumn 2014

CAP _SET P CAP Modify process capabilities

CAP _SY S_M ODU LE Insert/Remove kernel modules
CAP _SY S_RAW IO Modify Kernel Memory
CAP _SY S_P ACCT Configure process accounting
CAP _SY S_N ICE Modify Priority of processes
CAP _SY S_RESOU RCE Override Resource Limits
CAP _SY S_T IM E Modify the system clock
CAP _SY S_T T Y _CON F IG Configure tty devices
CAP _AU DIT _W RIT E Write the audit log
CAP _AU DIT _CON T ROL Configure Audit Subsystem
CAP _M AC_OV ERRIDE Ignore Kernel MAC Policy
CAP _M AC_ADM IN Configure MAC Configuration
Figure 5: The default networking model of Docker CAP _SY SLOG Modify Kernel printk behavior
CAP _N ET _ADM IN Configure the network
CAP _SY S_ADM IN Catch all

Limiting of Resources Table 1: Some capabilities disallowed in Docker containers

[24]
Denial-of-Service (DoS) is one of the most common attacks
on a multi-tenant system, where a process or a group of pro-
cesses attempt to consume all of the resources of the system,
the privileges of the superuser into capabilities, which the
thus disrupting normal operation of the other processes. In
kernel can independently enable or disable.
order to prevent this kind of attack, it should be possible to
limit the resources that are allocated to each container. Docker containers run on a kernel shared with the host
system, so most of their tasks can be handled by the host.
Cgroups are the key component that Docker employs to
As a result, in most cases, it is unnecessary to provide
deal with this issue. They control the amount of resources,
full root privileges to a container, thus removing some of
such as CPU, memory, and disk I/O, that any Docker con-
the root capabilities from a container does not affect the
tainer can use, ensuring that each container obtains its fair
usability or functionality of the container but effectively
share of the resources and preventing any container from
improves the security of the system. For example, the
consuming all resources. They also allow Docker to con-
CAP _N ET _ADM IN capability, which provides the abil-
figure the limits and constraints related to the resources allo-
ity to modify the system network, can be removed from a
cated to each container. For example, one such constraint is
container since all networking configuration can be handled
limiting the available CPUs available to a specific container.
by the Docker daemon before starting the container.
Docker allows configuration of the capabilities that a con-
4.2 Docker and Kernel Security Systems tainer can use. By default, Docker disables a large number of
Linux capabilities from its containers in order to prevent an
Some kernel security systems exist in order to harden the intruder to damage the host system even when the intruder
security of a Linux host system, including Linux capabili- has obtained root access within a container. Some of the
ties and Linux Security Module (LSM). Linux capabilities capabilities are presented in table 1, and their detailed de-
restricts the privileges assigned to each process. LSM pro- scription can be found in the Linux capabilities man page
vides a framework which allows the Linux kernel to support [9].
different security models. The LSMs that have been inte-
grated into the official Linux kernel include AppArmor [20],
SELinux [30], and Seccomp [14]. SELinux
This paper surveys Linux capabilities and two LSMs, Ap- SELinux is a security enhancement to the Linux system.
pArmor [20] and SELinux [30], which Docker currently sup- Linux comes with the standard Discretionary Access Con-
ports. Docker can also collaborate with Seccomp but only if trols (DAC) mechanism (i.e., owner/group and permission
LXC is used; thus, we do not include it in the survey. Even flags of an object) to control the access to an object. SELinux
though Docker does not support other security systems at the provides an additional layer of permission checking, called
moment, it does not interfere with them. Therefore, these Mandatory Access Control, after the standard DAC is per-
systems can run independently of Docker containers to pro- formed. In SELinux, everything is controlled by labels. Ev-
tect the host [2]. ery file/directory, process, and system object has a label. The
administrator of the system uses these labels to write rules to
Linux Capabilities control access between processes and system objects. These
rules are called policies. The SELinux policies can be di-
As stated in Linux capabilities man page [9], tradition- vided into three classes: Type enforcement, Multi-level secu-
ally, Unix systems classified processes into two categories: rity (MLS) enforcement, and Multi-category security (MCS)
privileged processes (owned by superuser or root) and un- enforcement.
privileged processes (owned by normal users). The kernel With the DAC mechanism, owners have full discretion
skipped all permission checks on the privileged processes over their objects, meaning that if the owners are compro-
but conducted full permission checking on unprivileged pro- mised, the attacker has control over all of their objects. In
cesses. However, the Linux kernel, since version 2.2, divides SELinux model, in contrast, the kernel manages and enforces
Aalto University T-110.5291 Seminar on Network Security Autumn 2014

all of the access controls over objects, not their owners. This it does not provide any filter on the network traffic passing
provides a secure separation for containers as it can prevent through the bridge. However, this problem can be solved if
processes, even with root privileges, within a container to the administrator manually adds filtering, such as ebtables
illegitimately access objects outside the containers. [6], to the bridge, or changes the networking connectivity to
Docker uses two classes of policy enforcement: Type en- a more secure one, such as virtual network.
forcement and MCS enforcement [24]. The Type enforce- It is also worth highlighting that if the operator runs a con-
ment protects the host from the processes in containers, and tainer as "privileged", Docker grants full access permissions
the MCS enforcement protects a container from another con- to the container, which is nearly the same as that of processes
tainer. running natively on the host. Therefore, it is more secure to
With Type enforcement, Docker labels all container pro- operate containers as "non-privileged".
cesses with svirt_lxc_net_t type and all content within a Furthermore, even though containers can provide higher
container with svirt_sandbox_f ile_t type. The processes density of virtual environments and better performance, they
running with svirt_lxc_net_t type can only access/write to have a bigger attack surface than virtual machines since con-
the content labeled with svirt_sandbox_f ile_t type, but tainers can directly communicate with the host kernel. How-
not to any other label on the system. Therefore, the pro- ever, it is possible to reduce the attack surface while main-
cesses running within containers can only use the content in- taining these advantages. For example, this can be achieved
side containers. However, only with this policy enforcement, by placing containers inside virtual machines.
Docker allows the processes in one container to have access
to the content of other containers. MCS enforcement is nec-
essary to solve this issue. When a container is launched, the 6 Conclusion and Future work
Docker daemon picks a random MCS label and then puts this
label on all of the processes and content of the container. The Container-based virtualization can provide higher den-
kernel only allow processes to access content with the same sity virtual environments and better performance than
MCS label, thus preventing a compromised process in one hypervisor-based virtualization. However, the latter is ar-
container from attacking other containers. gued to be more secure than the former. In this paper,
we conducted an analysis on Docker, which is one of the
AppArmor most popular container-based virtualization technologies, to
discover how safe its containers are. Our analysis shows
AppArmor is also a security enhancement model to Linux that Docker containers are fairly secure, even with the de-
based on Mandatory Access Control like SELinux, but re- fault configuration. The security level of Docker contain-
stricting its scope to individual programs. It permits the ers could also be increased if the operator runs them as
administrator to load a security profile into each program, "non-privileged" and enables additional hardening solutions
which limits the capabilities of the program. AppArmor sup- in Linux kernel, such as AppArmor or SELinux.
ports two modes: enforcement mode and complain/learning The future work after this paper could be to compare the
mode. The enforcement mode enforces the policies defined security of Docker containers with that of other container-
in the profile. However, in the complain/learning mode, the ization systems or with virtual machines. Such studies could
violations of profile policies are permitted, but also logged. lead to e.g. a detailed static analysis Docker or a broader
This log can be useful for developing new profiles later. view of security in containers in general.
On systems that support AppArmor, Docker provides an
interface for loading a pre-defined AppArmor profile when
launching a new container. This profile is loaded into Acknowledgement
the container in enforcement mode in order to ensure that
the processes in the container are restricted according to This research paper is made possible through the help and
the profile. If the administrator does not specify a profile support of Miika Komu, Roberto Morabito, Jimmy Kjäll-
when launching a container, the Docker daemon automat- man, and Tero Kauppinen from Nomadiclab.
ically loads a default profile to the container, which de-
nies access to important filesystems on the host, such as
/sys/f s/cgroups/ and /sys/kernel/security/. References
[1] Ansible. http://www.ansible.com/home/.
5 Discussion [Accessed 25 October 2014].
The analysis shows that Docker provides a high level of iso- [2] Containers & docker: How secure are they?
lation and resource limiting for its containers using names- https://blog.docker.com/2013/08/
paces, cgroups, and its copy-on-write file system, even with containers-docker-how-secure-are-they.
the default configuration. It also supports several kernel se- [Accessed 25 October 2014].
curity features, which help to hardening the security of the
host. The only problem we found with Docker was related [3] Device whitelist controller. https://www.
to its default networking model. The virtual ethernet bridge kernel.org/doc/Documentation/
which Docker uses as its default networking model, is vul- cgroups/devices.txt. [Accessed 12 Octo-
nerable to ARP spoofing and MAC flooding attacks since ber 2014].
Aalto University T-110.5291 Seminar on Network Security Autumn 2014

[4] Docker hub. https://hub.docker.com/. [Ac- [21] W. Felter, A. Ferreira, R. Rajamony, and J. Rubio. An
cessed 30 September 2014]. updated performance comparison of virtual machines
and linux containers. Technical Report RC25482
[5] Docker: Network configuration. https://docs. (AUS1407-001), IBM Research Division, July 2014.
docker.com/articles/networking/. [Ac-
cessed 24 September 2014]. [22] B. Hindman, A. Konwinski, M. Zaharia, A. Ghodsi,
A. D. Joseph, R. Katz, S. Shenker, and I. Stoica. Mesos:
[6] Ebtables. http://ebtables.netfilter. A platform for fine-grained resource sharing in the data
org/. [Accessed 25 October 2014]. center. In Proceedings of the 8th USENIX Confer-
[7] Kubernetes project. https://github.com/ ence on Networked Systems Design and Implementa-
googlecloudplatform/kubernetes. [Ac- tion, NSDI’11, pages 295–308, Berkeley, CA, USA,
cessed 10 November 2014]. 2011. USENIX Association.

[8] Libcontainer project. https://github.com/ [23] D. J. Walsh. Are docker containers really se-
docker/libcontainer. [Accessed 25 October cure? http://opensource.com/business/
2014]. 14/7/docker-security-selinux. [Accessed
25 October 2014].
[9] Linux capabilities. http://linux.die.net/
man/7/capabilities. [Accessed 12 October [24] D. J. Walsh. Bringing new security features to docker.
2014]. https://opensource.com/business/
14/9/security-for-docker. Available at:
[10] LXC. https://linuxcontainers.org/. [Ac- [Accessed 25 October 2014].
cessed 30 September 2014].
[25] A. Kivity, Y. Kamay, D. Laor, and U. Lublin. KVM:
[11] OpenVZ. http://openvz.org/. [Accessed 30 the linux virtual machine monitor. In Proceedings of
September 2014]. the Linux Symposium, volume 1, pages 225–230. 2007.
[12] PID namespaces in the 2.6.24 kernel. http://lwn. [26] D. Merkel. Docker: Lightweight linux containers for
net/Articles/259217/. [Accessed 30 Septem- consistent development and deployment. Linux J.,
ber 2014]. 2014(239), Mar. 2014.

[13] Puppet. http://puppetlabs.com/. [Accessed [27] P. Padala, X. Zhu, Z. Wang, S. Singhal, and K. G. Shin.
18 October 2014]. Performance evaluation of virtualization technologies
for server consolidation. HP Laboratories, 2007.
[14] SECure COMPuting with filters. https:
//www.kernel.org/doc/Documentation/ [28] N. Regola and J.-C. Ducom. Recommendations for vir-
prctl/seccomp_filter.txt. Available at: tualization technologies in high performance comput-
[Accessed 02 November 2014]. ing. In 2010 IEEE Second International Conference
on Cloud Computing Technology and Science (Cloud-
[15] Shipyard project. https://github.com/ Com), pages 409–416, Nov. 2010.
shipyard/shipyard. [Accessed 12 November
2014]. [29] E. Reshetova, J. Karhunen, T. Nyman, and N. Asokan.
Security of OS-level virtualization technologies. In
[16] Vagrant. https://www.vagrantup.com/. [Ac- Proceedings of the 2014 NordSec Conference, pages
cessed 15 November 2014]. 77–93, Norway, 2014.
[17] What is docker? https://docker.com/ [30] S. Smalley, C. Vance, and W. Salamon. Implementing
whatisdocker/. [Accessed 15 November 2014]. SELinux as a linux security module. NAI Labs Report
#01-043, NAI Labs, Dec. 2001. Revised May 2002.
[18] B. R. Anderson, A. K. Joines, and T. E. Daniels. Xen
worlds: Leveraging virtualization in distance educa- [31] S. Soltesz, H. Potzl, M. E. Fiuczynski, A. Bavier,
tion. In Proceedings of the 14th Annual ACM SIGCSE and L. Peterson. Container-based operating system
Conference on Innovation and Technology in Computer virtualization: A scalable, high-performance alterna-
Science Education, ITiCSE ’09, pages 293–297, New tive to hypervisors. In Proceedings of the 2Nd ACM
York, NY, USA, 2009. ACM. SIGOPS/EuroSys European Conference on Computer
Systems 2007, pages 275–287, USA, 2007. ACM.
[19] C. Burniske. Containers: The next generation of virtu-
alization? http://ark-invest.com/webx0/ [32] M. G. Xavier, M. V. Neves, F. D. Rossi, T. C. Ferreto,
containers-next-generation-virtualization. T. Lange, and C. A. F. De Rose. Performance eval-
[Accessed 22 November 2014]. uation of container-based virtualization for high per-
formance computing environments. In Proceedings of
[20] C. Cowan, S. Beattie, G. Kroah-Hartman, C. Pu, P. Wa- the 21st Euromicro International Conference on Paral-
gle, and V. Gligor. SubDomain: Parsimonious server lel, Distributed, and Network-Based Processing, pages
security. In Proceedings of the 14th USENIX Confer- 233–240, Washington, DC, USA, 2013. IEEE Com-
ence on System Administration, LISA ’00, pages 355– puter Society.
368, Berkeley, CA, USA, 2000. USENIX Association.