Skip to main content

Container Security with SELinux and CoreOS

At CoreOS, running containers securely is a number one priority. We recently landed a number of features that are helping make CoreOS Linux a trusted and even more secure place to run containers. As of the 808.0.0 release, CoreOS Linux is tightly integrated with SELinux to enforce fine-grained permissions for applications. Building on top of these permissions, our container runtime, rkt, has gained support for SVirt in addition to a default SELinux policy. The rkt SVirt implementation is compatible with Docker’s SVirt support, keeping you secure no matter what container runtime you choose.

Before covering these new features in detail, it’s important to step back and review how container technology is already keeping infrastructure secure.

Containers = Increased Security Through Isolation

Containers ease the deployment and management of applications and their dependencies, but the isolation that containers provide also results in increased security by reducing the degree to which applications can interact.

Containers place applications in restricted environments, isolated from each other using Linux functionality known as "namespaces." Each container runs in an independent namespace and is granted its own view of various operating system resources. This isolation prevents code within a container from interacting with code in other containers, resulting in an increase in security compared to running multiple non-containerized applications on the same system.

Unfortunately, the namespace support code is complicated and in the past, various bugs have allowed applications to escape from this namespace isolation and interfere with other containers. The known bugs have been fixed. In fact, technologies such as seccomp (a “secure computing” mechanism) reduce the number of system calls available to containerized applications and thus make it more difficult for exploitation of these bugs. However, further additional layers of security are recommended and can help mitigate any risk associated with future bugs.

SELinux Makes for Fine-Tuned Permissions

One important way to add a layer of security is with Security Enhanced Linux (SELinux). SELinux is a Linux kernel feature that allows for fine-grained restrictions to be applied to application permissions. Each process has an associated context, and, a set of rules defines the interactions permitted between contexts. This allows strict limits to be placed on what processes can do to each other and which resources they can access. A technology called SVirt, introduced by Red Hat, runs each container in a unique SELinux context. This context is permitted to access only the files and mount points required for that specific container – even if a process should manage to escape from the namespaces used to constrain it, the SELinux policy will still forbid it from accessing any other system resources or interacting with the contents of other containers.

CoreOS has introduced SVirt into the rkt container runtime and incorporated appropriate SELinux policy into the CoreOS Linux operating system. Out of the box, individual containers will run in independent SELinux contexts without the administrator having to take any further action. This implementation has also been designed to be compatible with the SVirt implementation in the Docker container runtime, and as such, running Docker under the CoreOS environment will benefit from additional isolation in the same way.

Let’s explore a quick example scenario. A bug in a service running inside a container allows an attacker to gain shell access to that container. The kernel namespaces that underlie containers will restrict that attacker from observing or interacting with any other containers running on the same system. However, if the attacker is able to take advantage of a kernel bug, they may be able to escape from the container environment. As multiple containers will typically be running as the same user, the attacker would then be able to attack any other containers hosted on the same system. In the SELinux scenario, the user will be restricted from doing this – every container runs in a different context and SELinux will forbid cross-context access, preventing any further damage from occurring. In fact, the SELinux policy is sufficiently strict that the attacker will be unable to launch any additional applications from the host environment.

Notes for Deploying

In order to avoid unexpected incompatibilities as this new feature is deployed, the default behaviour of the SELinux policy is to log policy violations but not to enforce them. See instructions on how to view these logs and enable policy enforcement.

This implementation is in its early days, and there are a couple of important limitations:

  • SELinux is currently unsupported when using Btrfs due to technical limitations in Btrfs. Upstream kernel work is continuing.
  • Support for shared volumes between containers when enforcing SELinux policy under rkt is currently incomplete but is being actively developed.

Next Steps for Security

CoreOS was founded on the principle of improving the security of the backend of the Internet. SELinux will continue to be an important security feature for CoreOS Linux projects. Other ways we are working to add security have been through virtualization, including using virtual machines to improve container security with the release of rkt v0.8.0. And, we are looking toward using TPM-based technologies to provide a fully attestable boot chain and cryptographically verifiable audit trails.

We welcome your participation in our projects and feedback in areas you find most important for your security needs. Join the discussion on the mailing lists for CoreOS Linux, rkt and more.