Pages

▼

Saturday, 14 November 2015

awesome linux containers

Table of Contents

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.
  • Cloud Foundry Foundation
    The Cloud is our foundry.

Specifications

  • Open Container Specifications
    This project is where the Open Container Initiative Specifications are written. This is a work in progress. 
  • App Container basics
    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.
  • Systemd Container Interface
    Systemd is a suite of basic building blocks for a Linux system. It provides a system and service manager that runs as PID 1 and starts the rest of the system. If you write a container solution, please consider supporting the following interfaces.

Clouds

  • Developer Cloud Platform
    PaaS from Docker creators.
  • 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. 
  • Mesosphere
    The Mesosphere Datacenter Operating System (DCOS) is a new kind of operating system that spans all of the machines in your datacenter or cloud. It provides a highly elastic, and highly scalable way of deploying applications, services and big data infrastructure on shared resources.
  • Kubernetes
    Manage a cluster of Linux containers as a single system to accelerate Dev and simplify Ops.
  • Jelastic
    Unlimited PaaS and Container-Based IaaS in a Joint Cloud Solution for DevOps.
  • Warden
    Manages isolated, ephemeral, and resource controlled environments. Part of Cloud Foundry - the open platform as a service project.

Hypervisors

  • Docker
    An open platform for distributed applications for developers and sysadmins. Standart de facto.
  • LXD
    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
    runc is a CLI tool for spawning and running containers according to the OCS specification.
  • Bocker
    Docker implemented in around 100 lines of bash.
  • Rocket
    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
    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
    Vagga is a fully-userspace container engine inspired by Vagrant and Docker, specialized for development environments.
  • libct
    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).
  • systemd-nspawn
    Spawn a namespace container for debugging, testing and building. Part of systemd.

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.
  • NsJail
    NsJail is a process isolation tool for Linux. It makes use of the the namespacing, resource control, and seccomp-bpf syscall filter subsystems of the Linux kernel.
  • Subuser
    Securing the Linux desktop with Docker.
  • 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
    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
    Works with Linux namespaces through glibc with pure python.

Security

Tools

  • Docker bench security
    The Docker Bench for Security is a script that checks for dozens of common best-practices around deploying Docker containers in production.
  • CoreOS Clair
    Open Source Vulnerability Analysis for your Containers.

Links

Levels of security problems

1) regular application
  • always untrusted -> know it
  • suid bit -> mount with nosuid
  • limit available syscall -> seccomp-bpf, grsec
  • leak to another container (bug in namespaces, filesystem) -> user namespaces with different uid inside for each cotainer: 1000 in container - 14293 and 15398 outside; security modules like selinux or apparmor
2) 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
3) system services like devices, network, filesystems
  • root -> more of services should work on host outside; isolate sensitive functions, run as non-privilaged context
  • full privilages -> isolate on kernel level
4) kernel drivers, network stack, security policies
  • absolute privilages -> run it in separate vm
5) general like immutable infrastructure
  • container is ro
  • write to small separate rw nosuid part

Technologies for security

Things are better. For example, most modern container technologies can make use of Linux's built-in security tools such as:
AppArmor, SELinux and Seccomp policies;
Grsecurity;
Control groups (cgroups);
Kernel namespaces
src
Sure, you're deploying seccomp, but you can't use selinux inside your container, because the policy isn't per-namespace (?? lxc uses apparmore for each container...)
sVirt - selinux for kvm
src
Major kernel subsystems are not namespaced like: 
  • SELinux
  • Cgroups
  • file systems under /sys
  • /proc/sys, /proc/sysrq-trigger, /proc/irq, /proc/bus
Devices are not namespaced: 
  • /dev/mem
  • /dev/sd* file system devices
  • kernel modules
If you can communicate or attack one of these as a privileged process, you can own the system.
src

Another Information Sources

  • sysdig-container-ecosystem
    The ecosystem of awesome new technologies emerging around containers and microservices can be a little overwhelming, to say the least. We thought we might be able to help: welcome to the Container Ecosystem Project.
  • doger.io
    This page is an attempt to document the ins and outs of containers on Linux. This is not just restricted to programmers looking to implement containers or use container like features in their own code but also Sysadmins and Users who want to get more of a handle on how containers work 'under the hood'.

from https://github.com/Friz-zy/awesome-linux-containers
--------
https://linuxcontainers.org
at