James Bottomley: Containers and Cloud Security

The idea behind this blog post is to take a new look at how cloud security is measured and what its impact is on the various actors in the cloud ecosystem. From the measurement point of view, we look at the vertical stack: all code that is traversed to provide a service all the way from input web request to database update to output response potentially contains bugs; the bug density is variable for the different components but the more code you traverse the higher your chance of exposure to exploitable vulnerabilities.[…]



NISTIR 8176: Linux app container security

Application Containers are slowly finding adoption in enterprise IT infrastructures. Security guidelines and countermeasures have been proposed to address security concerns associated with the deployment of application container platforms. To assess the effectiveness of the security solutions implemented based on these recommendations, it is necessary to analyze those solutions and outline the security assurance requirements they must satisfy to meet their intended objectives. This is the contribution of this document. The focus is on application containers on a Linux platform.

Keywords: application container; capabilities; Cgroups; container image; container registry; kernel loadable module; Linux kernel; namespace; TPM






Hardening Linux containers


Aaron Grattafiori of NCC Group has just published research on Linux containers and security hardening.

[…] Our recently-posted whitepaper starts off exploring the various motivations behind Linux containers and how they contrast with more traditional hardware virtualization on modern general purpose CPUs. The whitepaper then explores Linux namespaces, cgroups, and capabilities in depth, listing example use and illustrating potential risks. Next is an in-depth discussion of the various threats to any container deployment, either container to host attacks, cross-container attacks,and other potential threats to any container deployment, regardless of size. To counter these threats and add future defense in depth, this whitepaper also includes an exploration of key security features such as user namespaces, seccomp-bpf and Mandatory Access Control. While these features are often discussed as they relate to containers, the protections can be applied to any Linux application, regardless of container deployment. After exploring container basics, threats, and security features, an overview of Docker, LXC and CoreOS Rkt is included. This overview covers the container solution background, key components and includes a brief security analysis of each platform. This section ends by contrasting different container defaults, before enumerating various security recommendations to counter weaknesses (both in general for any container platform, and specifically for LXC, Docker and CoreOS Rkt). These configuration tweaks, security actions, strategies and recommendations help establish hardened Linux containers and adding defense in depth to any application deployment. To conclude, a number of future related technologies are briefly explored such as unikernels, microservices and other container platforms, this also includes a discussion of hybrid container/hardware virtualization using minimal hypervisors. […]

Full paper:

efitools now available for ARM

James Bottomley has a few new blog posts, two on efitools availability for ARM, and another on a container model for UEFI.


Constructing Architecture Emulation Containers

[…] the problem: how to build and test efitools for arm and aarch64 while not possessing any physical hardware.  The solution is to build an architecture emulation container using qemu and mount namespaces such that when its entered you find yourself in your home directory but with the rest of Linux running natively (well emulated natively via qemu) as a new architecture.  […] However, there’s a problem here: the installed binary emulator usually runs as /usr/bin/qemu-${arch}, so if you’re running a full operating system container, you can’t install any package that would overwrite that.  Unfortunately for me, the openSUSE Build Service package osc requires qemu-linux-user and would cause the overwrite of the emulator and the failure of the container.  The solution to this was to bind mount the required emulator into the / directory, where it wouldn’t be overwritten and to adjust the binfmt_misc paths accordingly. […]