Docker - the universal build system for system- and security-development (wiki)

Tags: #<Tag:0x00007f0ca74a35c0> #<Tag:0x00007f0ca74a32a0> #<Tag:0x00007f0ca74a3160>


Docker - usage and info wiki

This is a short Wiki article about how Docker works. Given that DevOps is a relatively new trend, the knowledge about the underlying technologies isn’t always up to date. Finding proper references might be more challenging than most people expect, given that the top results for common Docker related topics often contain wrong information.


Docker uses (Linux) kernel features and puts the known chroot concept on steroids. This way we can get a universal system to build and ship applications.

Docker, namespaces, capabilities and persistence

Today (Oct 2018) Docker is not based on LXC. This is a popular misinformation. LXC is a Type 2 Hypervisor.

Docker is not a Hypervisor per se, but here it gets a little blurry.

Docker builds processes in a portable and idempotent way. In order to do that is uses Kernel process isolation features such as Namespaces {1}, Control Groups (cgroups {2}) and Layer Capabilities {3}.

Docker’s lightweight process compartmentalization (“containers”) allows us to instantiate (pseudo-)segregated processes that share the same Operating System (OS) kernel. That means these dockerized processes show up in the operating system process list, just like normal processes.

(Source: Docker blog)

Docker’s architecture runs a daemon (docker-daemon) on the hosts, that connects the file-images with the container-processes. The service or daemon acts as the platform-specific layer (Windows, Linux, Mac OS X) and offers an interface to ascertain compatibility to the Docker Engine.

Alternatives to Docker include Rkt and Singularity.

In terms of virtualization Docker does offer certain Kernel-hosted features that may be defined as “micro” or “process” virtualization. Generally I want to avoid this terminology here. The OCI specification for container-runtimes {4} does not use “virtualizaion” as a lose term.

Unlike a virtual machine, a container does not need to boot the operating system kernel, so containers can be created in less than a second.

tl;dr: Docker is a platform. Its runtime components act as a OS-based wrapper around processes, a little like chroot or Jails. It makes processes idempotent and portable to make software deployments easier.


{1} Linux kernel documenation on Namespaces

{2} Linux kernel documentation on Cgroups

{3} Linux man page on capabilities

{4} OCI specification for container runtimes (Linux), Linux foundation project

Additionally, the underlying technology that Docker has donated to the OCI is broadly applicable to multi-architecture environments including Linux, Windows and Solaris and covers x86, ARM and IBM zSeries.
(Source: Docker blog)

Docker CE on Windows clients?

Docker (CE) on Windows (8, 10) uses Hyper-V for Linux and Windows containers. Hyper-V does not coexist well with other Hypervisors, such as VMware Workstation. Therefore it’s not a popular choice for development systems, even though Hyper-V itself is high-quality software.

There is some movement here, regarding the use of Windows process isolation features {1}. But a quick internet research may yield disappointing results related to Windows license concerns {2}.

{1} docker run --isolation=process is a possibility with customizations

{2} MS comments on their GitHub platform regarding the reasons for Hyper-V

Docker and the "Sandbox"

When developers refer to Docker (or OCI-based) runtimes, they often mention words like “isolation” or “sandbox”.

On Linux Docker uses a Syscall filter (called SecComp {1}) to limit the exposed system calls to the instantiated processes. This builds on the support of the respective underlying Linux kernel {2}. Such restricted processes are also called “sandboxed” processes {3}.


{1} Linux manpage, SecComp

{2} Docker profiles for SecComp

{3} LWN article on SecComp

Docker and the "Sandbox" on Windows

Generally Windows has Integrity Levels {1}, but Docker’s Process Isolation features are too new to determine the extend of this security feature at this point in time (Oct 2018).

A Hyper-V based Docker installation (common on Windows clients) will enable the platform to use SecComp from within the Linux guest OS, which will be virtualized. Given that most users aim to use Linux systems within Docker, this is more relevant.


{1} Windows Integrity Levels - MSDN

Docker on Mac OS X

Windows and Mac OS X systems do not have a Linux kernel. For most Docker containers this is needed. Therefore Docker on Mac OS X uses virtualization {1} as well, to instantiate a Linux guest.

HyperKit currently only supports macOS using the Hypervisor.framework. It is a core component of Docker For Mac.

(Source: GitHub repository)

As far as I know no one uses dockerized processes directly within XNU or Darwin environments. Mostly because it’s unlikely that this resembles a server deployment closely enough to provide reliable and comparable results.


{1} Hyperkit is a component of Docker on Mac OS X

Docker and Network isolation

Generally Docker does not have its own network stack by default. This means that at a common deployment the underlying Linux kernel will add virtual network interfaces, provide Network Address Translation (NAT) via IPtables and routing.

Untrusted code and Docker

Given that the idea of using Docker is to share one Operating System with multiple containerized processes, it is likely that the system has (indirect) access to important data. Such systems should never run untrusted code.

Docker features versatility over compartmentalisation.