Subscribe to the feed

table { border: #ddd solid 1px; } td, th { padding: 8px; border: #ddd solid 1px; } td p { font-size: 15px !important; }

In this series of blog posts, we would like to introduce how containers could be isolated between each other and from the host system, why Multi-Category Security container separation could be considered more secure than Multi-Level Security, how you can increase security with container pipelines and how to use multiple trusted networks with containers in high security environments.

The first part of the series is focused on how SELinux technology separates containers.  

Security Enhanced Linux (SELinux) is an additional security layer at the userspace level used by Red Hat Enterprise Linux (RHEL) and a number of other Linux distributions as an implementation of the mandatory access control concept. 

SELinux is central to our support of container separation as well as Multi-Level Security (MLS).  In containers we use SELinux to help prevent container attacks against the host file system. The standard Linux security model contains several security issues, like allowing the superuser “root” to bypass all security checks, possibility of using setuid bit to allow users to run an executable file with the permissions of the executable file owner, etc

This could cause security issues on systems. SELinux technology doesn’t recognize which Linux user executed a binary file or which security bits are set to file. SELinux is a labeling system and SELinux cares only about labels. From the SELinux point of view each object on the system has an SELinux label (every file, directory, socket file, symlink, shared memory, semaphore, fifo file, etc.) and also every subject (running process, Linux user entity). 

An example of a SELinux label for file /etc/passwd: system_u:object_r:passwd_file_t:s0

An example of a SELinux label for running process (container process): system_u:system_r:container_t:s0:c940,c967

The system_u label represents a SELinux user, which is not the same as a Linux user. Several Linux users can be mapped to a single SELinux user. This system_u user can be limited to a set of SELinux roles. 

SELinux users can have multiple roles but only one can be active and these roles could be limited to a set of SELinux types. In the example above, SELinux type is passwd_file_t (in file example) and container_t (in process example). In this post we won’t focus on the Role Based Access Control (RBAC) security model but only the Type Enforcement security model where only types are used. Interactions between types are defined in the SELinux security policy and describe access between subjects and objects. 

Example of an interaction (also called SELinux rule): allow container_t container_file_t:file {getattr open read}; 

The rule from this example shows that every process labeled as container_t can get attributes, open and read any file labeled as container_file_t on the filesystem! 

As you can see, in the rule there is no name of process or file mentioned, nor path nor Linux user. SELinux cares only about labels. 

The last part of the Security label is the MLS and Multi Category Security (MCS) piece. The combination of these two parts increases security because each sensitivity label is composed of a hierarchical classification and a set of non-hierarchical category compartments. With MCS, the SystemLow sensitivity label is s0 and the SystemHigh sensitivity label is s0:c0.c1023 while on an MLS system the two labels are SystemLow (s0) and SystemHigh s15:c0.c255

MLS policy provides a much stricter security policy than the targeted policy. In addition to more restrictive Type Enforcement and RBAC rules, it also provides an MLS implementation based on the Bell-LaPadula mandatory access control model, which focuses on data confidentiality and controlled access to classified information. In an MLS system the primary aim is to prevent "read up" or "write down". "Read up" means reading data that is classified at a level higher than the process that is reading it, "Write down" means writing data into a level lower than the process that is writing it. MLS is a key requirement to meet the common criteria label security profile and is popular with many high security users in the government and intelligence communities. 

MCS is used on container separation when running multiple containers with the same SELinux type is needed. Let’s say you’re running two containers with the same SELinux type container_t and both of them accessing three files with the same SELinux type container_file_t. The SELinux policy rule is then placed in the following SELinux policy: 

allow container_t container_file_t:file { getattr open read write append ioctl lock };

This example is saying that every container process labeled as container_t can read/write any file labeled as container_file_t. But how to separate these containers? Let’s put containers and files categories as described in the following table:

 

container_file_t:s0:c1

container_file_t:s0:c2

container_file_t:s0:c3

container_t:s0:c1,c2

can access

can access

cannot access

container_t:s0:c2,c3

cannot access

can access

can access

 

The container labeled container_t:s0:c1,c2 can access files labeled as container_file_t:s0:c1 and container_file_t:s0:c2 because categories {c1} and {c2} are subsets of set {c1,c2} but it cannot access container_file_t:s0:c3 because category {c3} is not subset of set {c1,c2}. A similar concept also applies to container_t:s0:c2,c3. When an object does not have any category (container_file_t:s0) an empty set is also part of every process set, which means every container with whatever category can access it. 

This figure illustrates  how SELinux separates containers on a kernel level. If one container wants to access another container or some object on the host file system, this access must be allowed in the SELinux policy loaded to kernel space and also categories must be properly assigned based on the example described above. 

 

Figure 1: How SE Linux separates containers on the kernel level

Figure 1: How SE Linux separates containers on the kernel level

In the first part of the new containers security series, we discussed what is the SELinux technology and how it could be helpful to increase container security, how containers are labeled and what MLS and MCS are. In the next part of the containers security series, we will compare MLS and MCS security models that could be used in container environments to separate containers between each other.


About the authors

Daniel Walsh has worked in the computer security field for over 30 years. Dan is a Senior Distinguished Engineer at Red Hat. He joined Red Hat in August 2001. Dan leads the Red Hat Container Engineering team since August 2013, but has been working on container technology for several years. 

Dan helped developed sVirt, Secure Virtualization as well as the SELinux Sandbox back in RHEL6 an early desktop container tool. Previously, Dan worked Netect/Bindview's on Vulnerability Assessment Products and at Digital Equipment Corporation working on the Athena Project, AltaVista Firewall/Tunnel (VPN) Products. Dan has a BA in Mathematics from the College of the Holy Cross and a MS in Computer Science from Worcester Polytechnic Institute.

Read full bio

Lukas Vrabec is a Senior Software engineer & SELinux technology evangelist at Red Hat. He is part of Security Controls team working on SELinux projects focusing especially on security policies. Lukas is author of udica, the tool for generating custom SELinux profiles for containers and currently maintains the selinux-policy packages for Fedora and Red Hat Enterprise Linux distributions. 

Read full bio

Simon Sekidde is a Solution Architect for the North America Red Hat Public Sector team specializing in the application of open source enterprise technologies for the Federal Department of Defense (DoD) customers.

Read full bio

Ben Bennett is a Senior Principal Software Engineer and is the group lead for the SDN, Routing, DNS, and Storage components of Red Hat OpenShift.  He has more than 25 years of experience working with networking, distributed systems, and Linux.

Read full bio
UI_Icon-Red_Hat-Close-A-Black-RGB

Browse by channel

automation icon

Automation

The latest on IT automation for tech, teams, and environments

AI icon

Artificial intelligence

Updates on the platforms that free customers to run AI workloads anywhere

open hybrid cloud icon

Open hybrid cloud

Explore how we build a more flexible future with hybrid cloud

security icon

Security

The latest on how we reduce risks across environments and technologies

edge icon

Edge computing

Updates on the platforms that simplify operations at the edge

Infrastructure icon

Infrastructure

The latest on the world’s leading enterprise Linux platform

application development icon

Applications

Inside our solutions to the toughest application challenges

Original series icon

Original shows

Entertaining stories from the makers and leaders in enterprise tech