Table of Contents
Why Mandatory Access Control Exists
Traditional Unix permissions and user accounts control who can access files and processes, but they assume that if a process runs as a user, it is allowed to do whatever that user can do. If an attacker compromises a service that runs as a powerful user, simple permissions no longer protect the system.
Mandatory Access Control, often shortened to MAC, adds another layer of security. Instead of relying only on users, groups, and sudo, the system enforces extra rules that even the root user or compromised services must follow. SELinux and AppArmor are two major MAC systems on Linux.
MAC systems like SELinux and AppArmor restrict what processes are allowed to do, even if traditional permissions would normally allow the action.
They do not replace standard permissions or firewalls. They add finer, centrally defined security policies that the kernel enforces.
SELinux in Brief
Security-Enhanced Linux, SELinux, is a MAC framework originally developed by the United States National Security Agency and released as open source. It is integrated into many distributions, most notably Fedora, Red Hat Enterprise Linux, CentOS Stream, AlmaLinux, and Rocky Linux, and can be enabled on others.
SELinux labels almost everything with security contexts. Files, processes, ports, and other objects receive labels that describe their type and role. The kernel checks every significant action against a policy that uses these labels.
From a high level, SELinux controls what a labeled process can do to labeled objects. For example, a web server process might be allowed to read files labeled as web content but not read user home directories or system passwords, even if traditional file permissions would permit it.
SELinux has global modes that control how strictly it behaves. On SELinux enabled systems you will often check or change the mode with tools such as getenforce and setenforce. The exact details of these commands belong to more practical chapters, but it is useful to know that SELinux can be completely enforcing, logging only, or disabled.
In enforcing mode, SELinux blocks actions that violate its policy.
In permissive mode, SELinux allows the actions but logs the violations for analysis.
In disabled state, SELinux is not active at all.
For basic administration, knowing which mode you are in and where to look for SELinux related logs is essential. Diagnostic tools can translate raw SELinux messages into human readable suggestions and help you decide whether to adjust the policy or fix an underlying misconfiguration.
AppArmor in Brief
AppArmor, short for Application Armor, is another MAC system that focuses on per application profiles instead of system wide labels. It is used by several distributions such as Ubuntu, openSUSE, and others.
AppArmor works by loading profiles that describe what a given program is allowed to do. Each profile typically references a program by its path. Inside the profile, paths to files, directories, and other resources are listed with allowed operations, such as read, write, or execute.
In contrast to SELinux, AppArmor does not use labels that are stored on files and other objects. Instead, it largely relies on file system paths and profile rules. This can make the mental model simpler for beginners, since you read the profile and see directly which paths are allowed for an application.
AppArmor has similar operating modes that control how strictly profiles are applied. On systems that use AppArmor, you will see references to complain mode and enforce mode.
In enforce mode, AppArmor prevents programs from performing actions outside their profile.
In complain mode, AppArmor logs policy violations but does not block them.
Profiles can also be disabled, which means AppArmor does not apply any restrictions to that program.
Managing AppArmor usually involves enabling or disabling profiles, switching them between enforce and complain modes, and inspecting logs to understand which operations would have been blocked.
Comparing SELinux and AppArmor
SELinux and AppArmor aim at the same goal, but they approach it with different models. Understanding the contrast will help you interpret documentation and decide which system is in use.
SELinux is label based. Every object and subject in the system has a security context, and the policy ties those contexts together. This design supports very fine grained rules and system wide consistency, at the cost of greater complexity. Policy files for SELinux resemble a small language with types, roles, and attributes.
AppArmor is path based. Profiles focus on individual programs and list what those programs can touch, mostly through file system paths. This often feels closer to how administrators think about applications in practice. It can be easier to read and adjust a profile for a specific service, especially for new users.
Many administrators describe SELinux as more powerful and flexible but harder to learn, and AppArmor as easier to get started with but somewhat less expressive. The exact differences are subtle and depend on particular use cases, but this general characterization is useful when approaching each system.
You do not normally run SELinux and AppArmor simultaneously.
A given distribution usually ships with one MAC system as its primary choice.
In practice, you accept the MAC framework that your distribution supports by default, and learn basic tasks such as checking status, interpreting logs, and enabling or relaxing protection for a specific service.
How MAC Fits into Everyday Administration
As a system administrator, you mostly encounter SELinux or AppArmor when something does not work as expected or when you deliberately harden a service.
A typical pattern is that a service fails to read a file, bind to a port, or write logs, even though file permissions and configuration seem correct. At that point, checking whether SELinux or AppArmor has blocked the action is an important troubleshooting step. These systems log denials that you can inspect, and they provide tools that summarize what policy change would be required to allow the action.
You can respond in several ways. You might keep the strict policy and adjust the service so that it uses permitted locations. You might extend the existing policy carefully to allow a needed action. As a last resort in a controlled environment, you might place a specific profile into logging only mode temporarily while you investigate.
Over time, you can also use SELinux or AppArmor proactively. For network facing services, you can limit file system access to only required directories and restrict other actions. This reduces the damage that a successful exploit can cause.
Do not disable SELinux or AppArmor wholesale as a first reaction to problems.
Instead, check logs, identify the precise denial, and consider a targeted adjustment.
Used thoughtfully, SELinux and AppArmor give Linux systems a strong additional layer of defense. For beginners, it is enough to recognize their presence, understand that they can block actions even for root owned services, and know that their behavior is controlled by policies or profiles that the kernel enforces.