Docker Security Whitepaper

Introduction to container secuirty whitepaper

Containers provide an additional layer of protection by isolating between the applications and the host, and between the applications themselves without using incremental resources of the underlying infrastructure and by reducing the surface area of the host itself.

Best practice recommendations for Linux systems administration include the application of the principle of least privilege. (...) The Docker container model supports and enforces these restrictions by running applications in their own root filesystem, allows the use of separate user accounts, and goes a step further to provide application sandboxing using Linux namespaces and cgroups to mandate resource constraints.

The default bounding set of capabilities inside a Docker container is less than half the total capabilities assigned to a Linux process (...). This reduces the possibility of escalation to a fully privileged root user through application-level vulnerabilities.

Containers have no default device access and have to be explicitly granted device access. These restrictions protect a container host kernel and its hardware, whether physical or virtual, from the running applications.

Docker containers use copy-on-write file systems, which allow use of the same file system image as a base layer for multiple containers.

The majority of these mandatory files, such as /sys and other files under /proc, come mounted as read-only

The simple deployment of Docker increases the overall system security levels by default, through isolation, confinement, and by implicitly implementing a number of best-practices, that would otherwise require explicit configuration in every OS used within the organization.

Attack vectors

Possible attack vectors against Golem nodes run by provider:

• Vector: task definition that tries to jailbreak docker sandbox; Countermeasures:
  • immutable task definitions (publishing hash of the task def on blockchain)
  • open source task defs
  • code review as a part of task def's presence on App Registry
• Vector: attack on software running inside docker container by specially prepared job (buffer overflow etc); Countermeasures:
  • Hardening and AppArmor profiles for software running inside container
  • task definitions should use up-to-date versions of software
  • watching CVE announcements for critical holes in software used in task definitions

Docker Security in Production

Nice presentation about Docker securities and problems link