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](/rhdc/managed-files/2020-05-12-selinux-image-figure-1.png)
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.
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.
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.
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.
More like this
Browse by channel
Automation
The latest on IT automation for tech, teams, and environments
Artificial intelligence
Updates on the platforms that free customers to run AI workloads anywhere
Open hybrid cloud
Explore how we build a more flexible future with hybrid cloud
Security
The latest on how we reduce risks across environments and technologies
Edge computing
Updates on the platforms that simplify operations at the edge
Infrastructure
The latest on the world’s leading enterprise Linux platform
Applications
Inside our solutions to the toughest application challenges
Original shows
Entertaining stories from the makers and leaders in enterprise tech
Products
- Red Hat Enterprise Linux
- Red Hat OpenShift
- Red Hat Ansible Automation Platform
- Cloud services
- See all products
Tools
- Training and certification
- My account
- Customer support
- Developer resources
- Find a partner
- Red Hat Ecosystem Catalog
- Red Hat value calculator
- Documentation
Try, buy, & sell
Communicate
About Red Hat
We’re the world’s leading provider of enterprise open source solutions—including Linux, cloud, container, and Kubernetes. We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.
Select a language
Red Hat legal and privacy links
- About Red Hat
- Jobs
- Events
- Locations
- Contact Red Hat
- Red Hat Blog
- Diversity, equity, and inclusion
- Cool Stuff Store
- Red Hat Summit