Fuzzing Docker containers with Trinity

Hypervisor breakouts are not as uncommon an occurrence as one would hope. In an effort to identify kernel problems that could lead to privilege escalation, we can “intelligently” fuzz for Docker container breakouts with Trinity:

Trinity is a system call fuzzer which employs some techniques to pass semi-intelligent arguments to the syscalls being called.

It passes illegal or unexpected parameters to various system calls in an attempt to crash the kernel. These attack vectors could they  be used as a basis for an exploit – in this case, a container breakout.

It comes with a health warning:

Warning: This program may seriously corrupt your files, including any of those that may be writable on mounted network file shares. It may create network packets that may cause disruption on your local network. Run at your own risk.

Eric Windisch has wrapped Trinity in a simple Dockerfile to test the container. Run with

docker run -u nobody ewindisch/trinity

This will generate a lot of output – you can leave Trinity running until it triggers some “interesting” behaviour.

This lwn.net article on Trinity that provides some background:

Trinity can be used in a number of ways. One possibility is simply to leave it running until it triggers a kernel panic and then look at the child logs and the system log in order to discover the cause of the panic. Dave has sometimes left systems running for hours or days in order to discover such failures. New system calls can be exercised using the -c command-line option described above. Another possible use is to discover unexpected (or undocumented) failure modes of existing system calls: suitable scripting on the log files can be used to obtain summaries of the various failures of a particular system call.

Go forth and fuzz.

Dockercon14 Tear Down

The inaugural DockerCon was a rousing success, with Docker 1.0 being announced and released. Here is a selection of choice Docker links:

Ways of working in a Dockerfile

Two interesting and opposing takes on the single-process-per-container model of Docker deployment. The first contains some good general practices (especially concerning package updates), the second provides a more in-depth look at and mitigation of Docker’s process management and exectution:

Much has changed since my first Dockerfile best practices post. I’ll leave the original post up for posterity and this post will include what has change and what you should do now.

via Dockerfile Best Practices – take 2.

You just built a container which contains a minimal operating system, and which only runs your app. But the operating system inside the container is not configured correctly. A proper Unix system should run all kinds of important system services. You’re not running them, you’re only running your app.

via Baseimage-docker: A minimal Ubuntu base image modified for Docker-friendliness.

Colouring in SELinux

Dan Walsh has produced an SELinux colouring book based on one of his articles. 

The SELinux primary model or enforcement is called type enforcement. Basically this means we define the label on a process based on its type, and the label on a file system object based on its type.

Imagine a system where we define types on objects like cats and dogs. A cat and dog are process types.

It proceeds to describe SELinux clearly and simply. Dan Walsh is the SELinux project lead at Red Hat, and the man who cries every time SELinux is disabled. So you should stop doing that – seriously.

The Twelve-Factor App

The Twelve-Factor App is a set of golden rules for web-based applications:

In the modern era, software is commonly delivered as a service: called web apps, or software-as-a-service. The twelve-factor app is a methodology for building software-as-a-service apps that:

  • Use declarative formats for setup automation, to minimize time and cost for new developers joining the project;
  • Have a clean contract with the underlying operating system, offering maximum portability between execution environments;
  • Are suitable for deployment on modern cloud platforms, obviating the need for servers and systems administration;
  • Minimize divergence between development and production, enabling continuous deployment for maximum agility;
  • And can scale up without significant changes to tooling, architecture, or development practices.

The twelve-factor methodology can be applied to apps written in any programming language, and which use any combination of backing services database, queue, memory cache, etc.

via The Twelve-Factor App.