Source-linked AI summary
Analysis of Docker Security
Thanh Bui
TL;DR
Virtualization’s demand for efficient and secure environments motivates an analysis of Docker, a lightweight container-based technology with security concerns. The paper examines Docker’s internal isolation and interaction with Linux security features, finding strong default isolation and resource limiting but a vulnerable default network model. It identifies non-privileged operation and additional kernel hardening as ways to increase security.
Problem
Virtualization requires solutions that combine dense, scalable, efficient, and secure user environments, while container-based virtualization introduces security concerns.
Method
The paper analyzes Docker’s internal isolation, resource limiting, and support for Linux kernel security features including SELinux and AppArmor.
Results
Docker provides a high level of isolation and resource limiting by default and supports several kernel security features, but its default networking model is vulnerable to ARP spoofing and MAC flooding.
Takeaways & Limitations
Running containers as non-privileged and enabling AppArmor or SELinux can increase Docker’s security level.
Takeaways & Limitations
Docker’s default bridge networking lacks traffic filtering and is vulnerable to ARP spoofing and MAC flooding, although administrators can add filtering or use more secure networking.
Abstract
from arXiv · showhide
Over the last few years, the use of virtualization technologies has increased dramatically. This makes the demand for efficient and secure virtualization solutions become more obvious. Container-based virtualization and hypervisor-based virtualization are two main types of virtualization technologies that have emerged to the market. Of these two classes, container-based virtualization is able to provide a more lightweight and efficient virtual environment, but not without security concerns. In this paper, we analyze the security level of Docker, a well-known representative of container-based approaches. The analysis considers two areas: (1) the internal security of Docker, and (2) how Docker interacts with the security features of the Linux kernel, such as SELinux and AppArmor, in order to harden the host system. Furthermore, the paper also discusses and identifies what could be done when using Docker to increase its level of security.
1 Introduction
Virtualization is expanding the need for dense, scalable, efficient, and secure environments. The paper analyzes Docker’s internal isolation and its interaction with Linux security features to assess and improve container security.
- Virtualization partitions computer systems into multiple isolated virtual environments and is widely adopted for server virtualization in data centers.
- Container-based and hypervisor-based virtualization are the two major classes, with containers providing a more lightweight and efficient environment.Container-based virtualization can run ten times more virtual environments on a physical server than hypervisor-based virtualization.
- Container-based virtualization offers efficiency advantages but also introduces security concerns.
- The paper analyzes Docker’s container isolation and its support for Linux kernel security features such as SELinux and AppArmor.It also discusses measures that could raise Docker’s security level.
- The paper presents an early analysis focused on Docker’s security aspects and is organized from virtualization background through Docker security analysis and hardening.
2 Virtualization Approaches
Container-based virtualization shares the host kernel to provide lightweight isolated environments, whereas hypervisor-based virtualization provides hardware-level virtual machines with separate guest operating systems. Containers offer higher density and performance but less environment diversity.
- Container-based virtualization runs multiple isolated environments at the operating-system level on a shared host kernel.Containers appear as normal processes externally and use shared or separately installed resources.
- Hypervisor-based virtualization provides hardware-level virtual machines, each containing an application, dependencies, a guest operating system, and a separate kernel.
- Container-based virtualization can deploy more environments and provide better performance because containers omit an entire guest operating system.
- Containers cannot support environments different from the host type; for example, Windows containers cannot run on a Linux host.
3 Docker Overview
Docker is an open-source container technology built around a daemon-managed engine, portable images, and shared image repositories. Its containers rely on Linux isolation and resource controls, layered images, and copy-on-write storage mechanisms.
- Docker provides interfaces for creating and controlling containers and packages applications into lightweight containers that can operate across environments without modification.It can deploy more virtual environments on the same hardware than other technologies.
- Docker consists of the Docker engine for virtualization and Docker Hub for sharing Docker images.
- Docker Engine: The Docker client sends RESTful API commands to the Docker daemon, which executes and manages containers locally or across hosts.
- Docker Container: Docker containers use namespaces for private resource views and cgroups for accounting and limiting process resources.
- Docker Container: Docker images consist of layered changes on a base image, allowing only updates to be distributed and supporting efficient image distribution.UnionFS combines files and directories from different file systems into one consistent file system, while copy-on-write isolates container changes.
- Docker Hub: Docker Hub stores public and private images, which users can search for, download, and verify for authenticity and integrity.
4 Docker Security Analysis
The security analysis asks whether Docker provides a safe application environment despite containers’ direct relationship with the host kernel. It examines both internal container security and interaction with additional kernel security systems.
- Virtual machines are claimed to provide stronger isolation because applications communicate with a VM kernel rather than directly with the host kernel.
- Docker may share the container security issue because it uses container-based virtualization, motivating analysis of container security and kernel security-system interactions.
4.1 Docker Internal Security
Docker’s internal security analysis evaluates isolation and resource-limiting requirements under a compromised-container attacker model. It finds that Docker uses namespaces, cgroups, copy-on-write storage, and device controls to separate containers, but its default bridge networking is vulnerable to ARP spoofing and MAC flooding.
- Security model and requirements: The analysis evaluates Docker against process, filesystem, device, IPC, network-isolation, and resource-limiting requirements under a compromised-container attacker model.The model assumes an attacker fully controls some containers while other containers remain under legitimate-user control.
- Process isolation: PID namespaces isolate container process-ID spaces, limiting process visibility while allowing the host to observe and affect container processes.Each container also receives an init-like PID 1 whose termination terminates processes in that namespace.
- Filesystem isolation: Mount namespaces and copy-on-write filesystems provide separate filesystem views and container-specific changes, although some kernel filesystems are not namespaced.Mount events inside a container are restricted to that container, while copy-on-write prevents containers sharing an image from discovering one another’s changes.
- Device isolation: Device Whitelist Controller, nodev mounts, and Docker’s default lack of extended privileges restrict device access and prevent creation or use of unauthorized device nodes.The controls address risks from sensitive nodes such as /dev/mem, /dev/sd*, and /dev/tty.
- IPC isolation: IPC namespaces separate semaphores, message queues, and shared-memory resources, preventing processes in one container from interfering with other containers.Docker assigns an IPC namespace to each container.
- Network isolation: Docker gives each container an independent networking stack, but its default bridge forwards incoming packets without filtering and is vulnerable to ARP spoofing and MAC flooding.The default bridge uses docker0 and virtual Ethernet interfaces to connect containers and the host.
- Resource limiting: Cgroups limit CPU, memory, disk-I/O, and other resources so one container cannot consume all host resources and disrupt others.They provide per-container constraints intended to mitigate denial-of-service attacks in multi-tenant systems.
4.2 Docker and Kernel Security Systems
Docker uses Linux capabilities and supported security modules to reduce container privileges and strengthen host protection. Its integration includes capability restriction, SELinux type and MCS enforcement, and AppArmor profiles applied in enforcement mode.
- Kernel security systems: Linux capabilities restrict process privileges, while LSMs provide security models including AppArmor, SELinux, and Seccomp.The paper surveys capabilities, AppArmor, and SELinux; Seccomp is excluded because Docker supports it only when LXC is used.
- Linux capabilities: Docker disables many Linux capabilities by default to limit host damage even if an attacker obtains root access inside a container.Operators can configure which capabilities a container may use.
- SELinux: SELinux adds label-based Mandatory Access Control after discretionary access checks, with policies governing access among processes and system objects.Its policy classes include type enforcement, MLS enforcement, and MCS enforcement.
- SELinux: Docker uses SELinux type enforcement to protect the host and MCS enforcement to protect containers from one another.Type enforcement labels container processes and content with distinct types and restricts process access to appropriately labeled content.
- AppArmor: AppArmor applies program-specific Mandatory Access Control through profiles, and Docker loads a specified or default profile in enforcement mode for new containers.The default profile denies access to important host filesystems when no profile is specified.
5 Discussion
The discussion concludes that Docker provides high isolation and resource limiting with its default configuration and supports kernel hardening features. Its principal security weakness is the unfiltered default bridge network, while privileged containers and shared-kernel exposure remain important boundaries.
- Findings: Docker provides high isolation and resource limiting by combining namespaces, cgroups, and copy-on-write storage, even with the default configuration.The analysis also finds support for several Linux kernel security features that help harden the host.
- Network limitation: The default virtual Ethernet bridge is vulnerable to ARP spoofing and MAC flooding because it provides no filtering for traffic passing through the bridge.Administrators can add filtering such as ebtables or change to a more secure networking model.
- Privilege boundary: Running a container as privileged grants full access permissions nearly equivalent to processes running natively on the host.The paper therefore identifies non-privileged operation as the more secure configuration.
- Shared-kernel boundary: Containers have a bigger attack surface than virtual machines because they directly communicate with the host kernel, although placing containers inside virtual machines can reduce that exposure.This preserves the stated density and performance advantages while adding another isolation layer.
6 Conclusion and Future work
The conclusion finds Docker containers fairly secure by default and identifies non-privileged operation plus AppArmor or SELinux as ways to increase security. The paper leaves comparison with other container systems and virtual machines for future work.
- Conclusion: Docker containers are described as fairly secure with the default configuration, while non-privileged operation and AppArmor or SELinux can further increase security.The conclusion frames these measures as practical ways to raise Docker’s security level.
- Future work: Future work includes comparing Docker’s security with other containerization systems or virtual machines and conducting more detailed static analysis.The authors also suggest broader study of container security.