Foundations
- OPEN CONTAINER INITIATIVE
The Open Container Initiative is a lightweight, open governance structure, to be formed under the auspices of the Linux Foundation, for the express purpose of creating open industry standards around container formats and runtime.
- Cloud Native Computing Foundation
The Cloud Native Computing Foundation will create and drive the adoption of a new set of common container technologies informed by technical merit and end user value, and inspired by Internet-scale computing.
Specifications
- App Container basics (⭐8.8k)
App Container (appc) is an open specification that defines several aspects of how to run applications in containers: an image format, runtime environment, and discovery protocol.
Clouds
- Google Cloud Platform
Run Docker containers on Google Cloud Platform, powered by Kubernetes. Google Container Engine actively schedules your containers, based on declared needs, on a managed cluster of virtual machines.
Hypervisors
- LXD (⭐4k)
Daemon based on liblxc offering a REST API to manage LXC containers.
- OpenVZ
OpenVZ is container-based virtualization for Linux. OpenVZ creates multiple secure, isolated Linux containers (otherwise known as VEs or VPSs) on a single physical server enabling better server utilization and ensuring that applications do not conflict.
Containers
- runc (⭐11k)
runc is a CLI tool for spawning and running containers according to the OCS specification.
- Rocket (⭐8.8k)
rkt (pronounced "rock-it") is a CLI for running app containers on Linux. rkt is designed to be composable, secure, and fast. Based on AppC specification.
- LXC (⭐4.1k)
LXC is the well known set of tools, templates, library and language bindings. It's pretty low level, very flexible and covers just about every containment feature supported by the upstream kernel.
- Vagga (⭐1.8k)
Vagga is a fully-userspace container engine inspired by Vagrant and Docker, specialized for development environments.
- libct (⭐101)
Libct is a containers management library which provides convenient API for frontend programs to rule a container during its whole lifetime.
- libvirt
A big toolkit to interact with the virtualization capabilities of recent versions of Linux (and other OSes).
Sandboxes
- Firejail
Firejail is a SUID sandbox program that reduces the risk of security breaches by restricting the running environment of untrusted applications using Linux namespaces, seccomp-bpf and Linux capabilities.
- Snappy
Snappy Ubuntu Core is a new rendition of Ubuntu with transactional updates - a minimal server image with the same libraries as today’s Ubuntu, but applications are provided through a simpler mechanism.
- xdg-app
xdg-app is a system for building, distributing and running sandboxed desktop applications on Linux.
Partial Access
- nsenter
Run program with namespaces of other processes. Part of the util-linux.
- ip-netns
Process network namespace management. Part of the iproute2.
- unshare
Run program with some namespaces unshared from parent. Part of the util-linux.
- python-nsenter (⭐136)
This Python package allows entering Linux kernel namespaces (mount, IPC, net, PID, user and UTS) by doing the "setns" syscall.
- butter
Python library to interface to low level linux features (inotify, fanotify, timerfd, signalfd, eventfd, containers) with asyncio support.
- pyspaces (⭐87)
Works with Linux namespaces through glibc with pure python.
Security / Links
Security / Levels of security problems
- always untrusted -> know it
- suid bit -> mount with nosuid
- limit available syscall -> seccomp-bpf, grsec
- system services like cron, ssh
- run as root -> isolate via bastion host or vm
- using /dev -> "devices" control group
The following device nodes are created in the container by default.
The Docker images are also mounted with nodev, which means that even if a device node was pre-created in the image, it could not be used by processes within the container to talk to the kernel.
/dev/console,/dev/null,/dev/zero,/dev/full,/dev/tty*,/dev/urandom,/dev/random,/dev/fuse
- root calls -> capabilities (cap_sys_admin warning!)
Here is the current list of capabilities that Docker uses: chown, dac_override, fowner, kill, setgid, setuid, setpcap, net_bind_service, net_raw, sys_chroot, mknod, setfcap, and audit_write.
Docker removes several of these capabilities including the following:
CAP_SETPCAP Modify process capabilities
CAP_SYS_MODULE Insert/Remove kernel modules
CAP_SYS_RAWIO Modify Kernel Memory
CAP_SYS_PACCT Configure process accounting
CAP_SYS_NICE Modify Priority of processes
CAP_SYS_RESOURCE Override Resource Limits
CAP_SYS_TIME Modify the system clock
CAP_SYS_TTY_CONFIG Configure tty devices
CAP_AUDIT_WRITE Write the audit log
CAP_AUDIT_CONTROL Configure Audit Subsystem
CAP_MAC_OVERRIDE Ignore Kernel MAC Policy
CAP_MAC_ADMIN Configure MAC Configuration
CAP_SYSLOG Modify Kernel printk behavior
CAP_NET_ADMIN Configure the network
CAP_SYS_ADMIN Catch all
uses /proc, /sys -> remount ro, drop cap_sys_admin; security modules like selinux or apparmor; some part of this fs are "namespace-aware"
Docker mounts these file systems into the container as "read-only" mount points.
. /sys
. /proc/sys
. /proc/sysrq-trigger
. /proc/irq
. /proc/bus
Copy-on-write file systems
Docker uses copy-on-write file systems. This means containers can use the same file system image as the base for the container. When a container writes content to the image, it gets written to a container specific file system. This prevents one container from seeing the changes of another container even if they wrote to the same file system image. Just as important, one container can not change the image content to effect the processes in another container.
- uid 0 -> user namespaces, uid 0 mappet to random uid outside
- system services like devices, network, filesystems
- kernel drivers, network stack, security policies
- general like immutable infrastructure
- write to small separate rw nosuid part
Security / Technologies for security
- /proc/sys, /proc/sysrq-trigger, /proc/irq, /proc/bus
- /dev/sd* file system devices
]]>