Linux Security Modules: AppArmor vs. SELinux

Introduction

Welcome to a new module focused on Kernel Security and Isolation Mechanisms. In previous modules, we've explored the kernel's architecture, process management, and advanced debugging. Now, we shift our focus to how the kernel protects itself and the system from malicious or buggy software. This is a critical area for embedded systems, virtualization, and any environment where reliability and security are paramount.

This lesson tackles the learning outcome: Explain the purpose of the Linux Security Module (LSM) framework and compare AppArmor and SELinux. We will start by understanding why the traditional UNIX permission model is not enough, then dive into the elegant solution provided by the LSM framework. Finally, we'll compare the two most prominent MAC (Mandatory Access Control) systems built on LSM, helping you understand their design philosophies and trade-offs.

1. The Limits of Traditional Linux Security

The standard security model in UNIX-like systems, including Linux, is Discretionary Access Control (DAC). You're already familiar with this: it's the classic system of users, groups, and permissions (read, write, execute) for files and directories. The "discretionary" part means that the owner of an object has the discretion to change its permissions.

While effective for multi-user separation, DAC has a fundamental weakness: the root user is omnipotent. If an attacker can compromise a process running as root, they have complete control over the system and can bypass all DAC permissions.

To understand this limitation more clearly and to introduce the alternative, Mandatory Access Control (MAC), please watch the following segment.

Security-Enhanced Linux for mere mortals

This clip from the 'Security-Enhanced Linux for mere mortals' presentation at a Red Hat Summit provides a concise explanation of the difference between Discretionary Access Control (DAC) and Mandatory Access Control (MAC).

Watch the section from 03:47 to 06:08. Pay close attention to the explanation of why a user having 'discretion' over their files is a problem and how MAC introduces a system-wide, non-discretionary policy that even the root user cannot override.

In a MAC system, access decisions are based on a system-wide policy established by an administrator. This policy is mandatory and cannot be changed even by the owner of the object or the root user. The goal is to enforce the principle of least privilege, ensuring a process (even a compromised one) can only perform actions explicitly allowed by the security policy.

This begs the question: how can the Linux kernel, with its established DAC model, support various MAC implementations? The answer is the Linux Security Module framework.

2. The Linux Security Module (LSM) Framework

Instead of hardcoding one specific MAC implementation into the kernel, the developers created a generic framework that allows different security models to be "plugged in" as loadable modules. This is the Linux Security Module (LSM) framework.

The core idea of LSM is to place "hooks" at critical points within the kernel's code. These hooks are function calls that are executed just before the kernel performs a sensitive operation, such as accessing an inode, a task structure, or a network socket.

To understand the design and purpose of LSM, let's turn to the original paper that introduced it.

[PDF] Linux Security Module Framework

This paper, 'Linux Security Module Framework,' was presented at the 2002 Ottawa Linux Symposium and provides the definitive explanation of LSM's design and motivation. It was written by the key architects of the framework.

Please read the following sections of the PDF: Section 1: Introduction (page 1): This sets the stage, explaining the 'Tower of Babel' problem with multiple kernel security patches and how LSM aims to solve it. Section 2: Design and Implementation (page 2): Focus on the design goals (generic, simple, efficient) and the core architectural decision to place hooks inside the kernel to mediate access to internal kernel objects, rather than at the system call boundary. Section 3.1: Policy Registration (page 3): Understand how a security module registers itself with the LSM framework using the security_ops structure. Note that only one primary security module can be active at a time.

As the paper describes, LSM provides a standardized API for policy enforcement. When a kernel code path reaches an LSM hook, it calls a function pointer from the currently registered security_ops structure. The security module (e.g., SELinux or AppArmor) provides the implementation for this function, which checks the action against its policy and returns an answer: "yes" (access granted) or "no" (access denied).

This diagram provides a clear visual of where the LSM hook fits into the process of opening a file.

LSM Hook in System Call Flow — This diagram shows the execution flow of an `open` system call. The LSM hook is strategically placed after standard error and DAC checks but before the kernel grants final access to the inode. This allows the security module to make the ultimate access control decision.

With a solid understanding of the LSM framework, we can now examine its two most widely used implementations.

3. Comparing SELinux and AppArmor

SELinux (Security-Enhanced Linux) and AppArmor (Application Armor) are both mature, powerful security modules that use the LSM framework to enforce Mandatory Access Control. However, they are built on fundamentally different design philosophies.

Security Model: Labels vs. Paths

The most significant difference lies in their core security models.

SELinux is label-based. Every single subject (process) and object (file, directory, socket, etc.) on the system is assigned a security label, also known as an SELinux context. The security policy consists of rules that define the allowed interactions between these labels. For example, a rule might state: "A process with the label httpd_t is allowed to read a file with the label httpd_sys_content_t." This approach is independent of file paths.
AppArmor is path-based. Security policies, called "profiles," are attached to specific applications based on their executable path (e.g., /usr/sbin/nginx). The rules within a profile specify which files (by their path) the application is allowed to access and with what permissions (e.g., read, write, execute).

The following short video provides a good high-level overview of this key difference and its implications.

DEMYSTIFY: The Choice Between SELinux or AppArmor

The video 'DEMYSTIFY: The Choice Between SELinux or AppArmor' gives a quick, clear comparison of the two systems.

Watch from 00:42-00:56 to confirm they are both LSMs, then from 02:50-04:22. Focus on how SELinux is described as a 'comprehensive security solution' controlling more than just files, while AppArmor is presented as focusing primarily on 'file access'.

Granularity, Complexity, and Use Cases

This fundamental difference in their security models leads to significant trade-offs in granularity, complexity, and typical use cases. Let's delve deeper into SELinux first.

Security-Enhanced Linux for mere mortals

Let's return to the Red Hat Summit presentation, which offers an excellent deep dive into the core concepts of SELinux.

Watch the section from 08:03 to 13:44. This segment explains the two fundamental concepts of SELinux: labeling and type enforcement. The Apache web server example clearly illustrates how different files, directories, processes, and network ports associated with a single service all have distinct labels (types) and how policy enforces interactions between them.

As you saw, SELinux's label-based type enforcement is incredibly powerful and fine-grained. It can control access to network ports, IPC mechanisms, and specific system calls, not just files. This power, however, comes with significant complexity in policy writing and management.

SELinux LSM Module Architecture — This diagram shows the internal architecture of the SELinux module. When a kernel object manager triggers an LSM hook, the request goes to the Access Vector Cache (AVC) for a fast lookup. If the permission is not cached, the request goes to the security server, which consults the loaded policy to make a decision.

Now, let's formalize the comparison with AppArmor.

SELinux vs AppArmor: The Hard Truth About Linux Security - TuxCare

The article 'SELinux vs AppArmor: The Hard Truth About Linux Security' from TuxCare provides a structured comparison that is useful for summarizing the key differences.

Read the following parts of the article: The definitions under 'What Is AppArmor?' and 'What Is SELinux?'. The numbered list in 'The Differences Between AppArmor vs SELinux' which compares them across multiple axes. The 'Pros and Cons' tables for both AppArmor and SELinux. The section 'Which One Should You Choose?' to understand the decision criteria.

Summary of Comparison

Here is a summary table based on what you've learned:

Feature	SELinux	AppArmor
Security Model	Label-based (Type Enforcement)	Path-based
Policy Granularity	Very high (files, sockets, IPC, capabilities, network controls)	Medium (primarily file access, with some capability and network rules)
Complexity	High, steep learning curve. Requires specialized tools (`semanage`, `audit2allow`).	Low, easy to learn. Profiles are human-readable text files.
Policy Application	System-wide. Policy rules apply to labels, not processes directly.	Per-application. Profiles are tied to executable paths.
Flexibility	Extremely flexible. Supports Role-Based Access Control (RBAC) and more.	Less flexible. Well-suited for confining specific server applications.
Default Distribution	RHEL, Fedora, CentOS, Android	Ubuntu, SUSE, Debian

4. Interview Scenario

Now, let's apply this knowledge to a typical interview problem.

Scenario: You are designing a secure embedded Linux system for an IoT gateway. The gateway runs a third-party, closed-source application that receives data from sensors and forwards it to a cloud service. You cannot audit the application's source code. Your security requirements are:

The application must only be able to communicate with a specific cloud server endpoint (api.cloud.com on port 443).
It must only be able to read from the sensor device files in /dev/.
It must only be able to write log files to /var/log/iot_app/.
It must be prevented from accessing any other part of the filesystem, executing other programs, or opening arbitrary network connections.

Question: Which security mechanism, SELinux or AppArmor, would be the more robust choice to confine this application, and why? Justify your choice by comparing their core principles and how they would address the requirements.

Click here for the analysis

Answer: SELinux is the more robust choice for this high-security scenario.

Justification:

Network Control: SELinux excels at fine-grained network control. A policy can be written to allow the application's process type (iot_app_t) to only connect to a specifically labeled network port and host. AppArmor's network rules are generally less granular and might only be able to specify broad rules like "allow TCP outbound," making it harder to restrict the connection to a single endpoint.
Robustness of Confinement: AppArmor's path-based rules can sometimes be tricked. For instance, if an attacker finds a way to create a hard link to a sensitive file (e.g., /etc/shadow) inside the allowed log directory /var/log/iot_app/, the AppArmor profile might permit access because the path appears valid. SELinux's label-based model is immune to this; the policy is based on the label of the target file (etc_shadow_t), not its path. Access would be denied regardless of how the file is reached.
Comprehensive Control: The requirement to prevent the execution of other programs and other non-file-based actions is better handled by SELinux's comprehensive control over process transitions and system capabilities.

While AppArmor would be simpler to configure for just the file access rules (requirements 2 and 3), the strict network control and the need for a more resilient sandbox against unforeseen exploits make SELinux's higher complexity a necessary and justified trade-off for this embedded gateway.

Conclusion

In this lesson, you have learned how the Linux kernel moved beyond the limitations of Discretionary Access Control by creating the flexible Linux Security Module framework. This framework enables powerful Mandatory Access Control systems like SELinux and AppArmor to enforce system-wide security policies that even root cannot bypass.

Key Takeaways:

Discretionary Access Control (DAC) is the traditional UNIX model (owner/group/other permissions), which is insufficient against a compromised root process.
The Linux Security Module (LSM) framework provides kernel hooks that allow pluggable security modules to enforce Mandatory Access Control (MAC).
SELinux is a label-based MAC system offering extremely fine-grained control over nearly every kernel object. Its power comes at the cost of high complexity.
AppArmor is a path-based MAC system that is much simpler to learn and manage. It is excellent for confining applications based on filesystem access but is less granular than SELinux.
The choice between them depends on the security requirements, the complexity you are willing to manage, and the specific controls needed for the workload.

Preview of the Next Lesson:

While LSMs provide policy-based control over actions, another class of security features aims to defeat entire categories of exploits, particularly memory corruption attacks. In our next lesson, we will explain kernel hardening features (KASLR, stack canaries, SMEP/SMAP) and verify their status on a system. These are preventative measures that make it much harder for an attacker to successfully exploit a bug, even if they find one.

Recommended resources