SELinux vs AppArmor: Which MAC Framework Fits Your Server?

SELinux and AppArmor both enforce Mandatory Access Control (MAC) on Linux, restricting what processes can do even if they gain root. The difference is in how they do it. SELinux assigns persistent labels to every file and process. AppArmor uses file path rules instead. That one design choice shapes everything else: complexity, security depth, and which distro ships which tool by default.

How SELinux Works

SELinux was originally developed by the NSA and ships by default on RHEL, CentOS, Fedora, and Rocky Linux. It labels every object on the system, including files, processes, ports, and sockets, with a security context in the format user:role:type:level. The type field does most of the heavy lifting through a mechanism called Type Enforcement (TE).

For example, the Apache web server runs as httpd_t. Web content files carry a different type. If no policy rule explicitly allows httpd_t to access that content type, the request is denied. This is a deny-by-default model. Nothing is allowed unless a rule says otherwise.

SELinux also supports Multi-Level Security (MLS) and Multi-Category Security (MCS), which classify data by sensitivity level and restrict access accordingly. MCS is what gives SELinux its strong container isolation, keeping containers separated from each other and from the host. This matters in Kubernetes and OpenShift environments where pods share a node.

The trade-off is complexity. SELinux has a steep learning curve. Troubleshooting access denials means reading audit logs, understanding security contexts, and sometimes generating custom policy modules with audit2allow. For teams without dedicated security staff, that overhead is real.

How AppArmor Works

AppArmor takes a different approach. Instead of labelling objects, it attaches security profiles to applications based on their file paths. A profile for /usr/sbin/nginx defines which directories Nginx can read, which ports it can bind, and what capabilities it needs. Profiles are plain text files stored in /etc/apparmor.d/.

AppArmor is the default MAC framework on Ubuntu, Debian, and SUSE. It has been part of the Linux kernel since version 2.6.36. Applications without a profile fall back to standard Linux DAC permissions.

AppArmor runs in two modes per profile: Enforce (blocks and logs violations) and Complain (logs violations without blocking). This makes it practical to roll out new profiles gradually. Start in Complain mode, review the logs, tighten the profile, then switch to Enforce.

Tools like aa-genprof and aa-logprof help build profiles interactively by watching what an application does and generating rules from its behaviour. Compared to SELinux policy modules, the syntax is much easier to read and edit by hand.

The downside is that path-based rules don't follow files when they move. A hard link or bind mount can, in theory, bypass a path-based restriction. AppArmor also lacks native MLS/MCS support, so it can isolate containers from the host but not from each other the way SELinux does.

Side-by-Side Comparison

Basic Configuration

SELinux

Check the current status:

sestatus
getenforce

Start in Permissive mode to log violations without blocking anything:

setenforce 0

Use the "targeted" policy for most servers. It confines high-risk services like web servers and databases while leaving everything else unrestricted. Make it permanent in /etc/selinux/config:

SELINUX=enforcing
SELINUXTYPE=targeted

Inspect security contexts on files and processes:

ls -Z /var/www/html
ps -eZ | grep httpd

If a service uses a non-standard port, update the policy:

semanage port -a -t ssh_port_t -p tcp 9999

For custom applications generating access denials, create a policy module from the audit log:

ausearch -m avc -ts recent | audit2allow -M my_custom_policy
semodule -i my_custom_policy.pp

AppArmor

Check which profiles are loaded:

sudo aa-status

Install the utilities package if you need profile management tools:

sudo apt install apparmor-utils

Generate a profile interactively while the application runs:

sudo aa-genprof /path/to/binary

Refine the profile by scanning logs for violations:

sudo aa-logprof

Switch a profile between modes:

sudo aa-enforce /etc/apparmor.d/usr.sbin.nginx
sudo aa-complain /etc/apparmor.d/usr.sbin.nginx

Which One Should You Use?

The practical answer for most admins: use whatever your distro ships. RHEL, CentOS, Fedora, and Rocky Linux come with SELinux. Ubuntu, Debian, and SUSE come with AppArmor. Both frameworks have mature tooling and policies for their native platforms. Switching to the non-default option on any distro adds work and reduces community support.

Beyond that, let your requirements decide:

• Choose SELinux if you need compliance with PCI DSS, HIPAA, or DISA-STIG. If you run multi-tenant container workloads on Kubernetes or OpenShift. If you need container-to-container isolation on shared hosts. If your environment handles classified or sensitivity-tiered data.
• Choose AppArmor if you run Ubuntu or Debian and want MAC protection without a steep ramp-up. If your setup is a single server or small cluster running standard web services. If fast deployment matters more than granular, label-level control.

Both frameworks add minimal runtime overhead. SELinux caches access decisions in its Access Vector Cache. AppArmor's policy loading can add a small delay at boot but has negligible impact at runtime. For most hosting workloads, neither will be the bottleneck.

If you need a reliable hosting foundation with full root access to configure either framework, FDC's dedicated servers or VPS give you the control to set up SELinux or AppArmor the way your environment requires.