Skip to main content

Technologies for container isolation: A comparison of AppArmor and SELinux

This article takes a look at AppArmor and SELinux security technologies and explores the capabilities of each.
Image
Four semanage commands to keep SELinux in enforcing mode
"Going nowhere" by Damian Gadal is licensed under CC BY 2.0

I researched how containers, virtual machines (VMs), and processes, in general, are separated by different technologies—namely, AppArmor and SELinux. My goal was to compare these solutions for isolation/separation capabilities in the cloud world.

Just as a reminder, Red Hat Enterprise Linux uses SELinux technology to separate processes, containers, and VMs. OpenShift also uses this technology.

The first option is an isolation technology called AppArmor, which is a very similar technology to SELinux. However, it is not label-based. AppArmor security profiles, which are equivalent to SELinux security policies, look more user-friendly, but that’s because AppArmor is less complicated and controls fewer operations.

Both SELinux and AppArmor supports the Type Enforcement security model, which is a type of mandatory access control, based on rules where subjects (processes or users) are allowed to access objects (files, directories, sockets, etc.). However, what AppArmor doesn’t have is Multi-Level Security (MLS) and Multi-Category Security (MCS). This means that AppArmor usage in environments requiring MLS is very difficult, if not impossible.

MLS/MCS capabilities is a big difference between AppArmor and SELinux. With AppArmor, it’s not possible to keep separation between containers. AppArmor separates containers from the host, but the default container policy is very loose and needs to be improved to prevent access to the entire host filesystem. Separation between each container is not possible because AppArmor does not support MCS. SELinux, by default, separates containers from each other and also from the host filesystem. Kata containers could be another solution and a better choice in the cloud for container separation.

The second option is to use virtual machines (VMs) to isolate containers. This approach is accomplished by putting container pods inside of VMs. This brings significant overhead to the cloud infrastructure. With SELinux, it’s possible to isolate pods without the need to use VMs.

You can even generate a specific SELinux policy for custom containers via the udica tool.

The following table summarizes differences between SELinux and AppArmor technologies:

Technology

Type Enforcement 

MLS/MCS

Policy generator

Generator for containers

AppArmor

Yes

No

Yes

No

SELinux

Yes

Yes

No*

Yes

* SELinux has tooling to do it (audit2allow), rather than a single wrapper
like AppArmor has.

To summarize, SELinux is a more complex technology that controls more operations on a system and separates containers by default. This level of control is not possible with AppArmor because it lacks MCS. In addition, not having MLS means that AppArmor cannot be used in highly secure environments.

References:

[1] https://www.redhat.com/en/topics/linux/what-is-selinux

[2] https://apparmor.net/

[3] https://selinuxproject.org/page/NB_TE

[4] https://selinuxproject.org/page/NB_MLS

[5] https://katacontainers.io/

[6] https://github.com/containers/udica

 

[ Getting started with containers? Check out this free course. Deploying containerized applications: A technical overview. ]

Topics:   Containers   Security  
Author’s photo

Lukas Vrabec

Lukas Vrabec is a product owner and SELinux technology evangelist at Red Hat. He is leading SELinux development team. Lukas is long-term Fedora contributor and Red Hat Enterprise Linux developer. He is author of udica, the tool for generating custom SELinux profiles for containers. More about me

Try Red Hat Enterprise Linux

Download it at no charge from the Red Hat Developer program.