How SELinux separates containers using Multi-Level Security

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:

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

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.