AppArmor vs SELinux

Core Philosophy & Access Control Models

While it is commonly simplified that AppArmor is "Path-based" and SELinux is "Label-based", the core difference lies in their perspective: using a Application-Centric vs System-Centric model.

• AppArmor (Application-Centric): AppArmor focuses on the perspective of the application. Policy authors define what a specific application can or cannot do through rules for each kind of access (files, network, etc). The goal is to reduce the complexity for the human by aligning the policy with the application's view, pushing the complexity of translating this to enforcement into the kernel.
• SELinux (System/Object-Centric): SELinux tends to take a system-wide perspective, striving for a clean mathematical model where every resource (process, file, socket) has a label (type). Access is determined by a global policy defining how these labels interact. This allows to perform static offline analysis (e.g., analyzing a disk image without running it). However, this pushes the complexity onto the policy author, who must manage the interactions of many thousands of system-wide rules and abstract labels.

Ease of Use & Learning Curve

AppArmor profiles are human-readable text files. Reviewing a profile is generally very easy, even for non-experts.

SELinux policies are compiled binary modules. While powerful, troubleshooting denials requires analyzing audit logs to find label mismatches. Some tools are aimed at simplifying this process, but the learning curve remains steeper due to the abstraction of "types" and "domains".

Security Models

Both AppArmor and SELinux implement Mandatory Access Control (MAC), but they approach advanced security models differently:

MAC (Mandatory Access Control)

• AppArmor focuses on Path-based MAC, where profiles are attached to executable paths.
• SELinux focuses on Type Enforcement (TE), where labels are attached to inodes and processes.

RBAC (Role-Based Access Control)

• SELinux: Has native support for RBAC. Users are mapped to SELinux users, which are then mapped to roles, and finally to domains (types).
• AppArmor: Implements RBAC via PAM AppArmor. This module allows assigning specific profiles (acting as "roles") to users upon login, effectively confining them to a pre-defined set of capabilities.

MLS (Multi-Level Security)

• SELinux: Supports native MLS through sensitivity labels to enforce strict "read-down, write-up" policies.
• AppArmor: Could theoretically support MLS through hierarchical profile design, but this approach is not widely used in practice.

Granularity & Flexibility

Both AppArmor and SELinux allow to express a wide range of very fine-grained security policies.

• AppArmor: Primarily designed for application confinement. It effectively isolates specific services from the rest of the system. By loading profiles for all applications on the system (or at least the sensitive ones), it is possible to achieve system-wide confinement.
• SELinux: Offers system-wide granularity by design. It can enforce constraints on all kernel structures through the security kernel pointer.

Mediation Scope

The number of LSM hooks implemented by a security module is often used as a metric for comparison, but it requires nuance.

• Mediation Coverage: Currently, SELinux implements more LSM hooks than AppArmor (217 vs 80 in Linux v6.19), providing a more complete coverage of kernel mediation. AppArmor is actively working on increasing its mediation coverage to reduce this gap.
• Granularity: While SELinux covers more hooks, AppArmor can offer finer-grained effective security in specific scenarios due to implementation choices.
  • Desktop Scenarios: By default, all Linux users in Red Hat Enterprise Linux, including users with administrative privileges, are mapped to the unconfined SELinux user unconfined_u (source. In contrast, AppArmor specific profiles are always enforced, regardless of the user context.
  • Container Policy: On Red Hat based systems, Docker’s SELinux confinement exists but is disabled by default unless the daemon is started with --selinux-enabled or the equivalent configuration option source. On Ubuntu/Debian, Docker instead uses AppArmor’s path-based model by attaching the docker-default profile to containers unless overridden source. LXD generates and applies a distinct AppArmor profile per container, stored under /var/lib/lxd/security/apparmor/profiles/<container-name> source.

The choice often comes down to the specific interactions you need to mediate and the operational model of your environment.

Performance

Most benchmarks show that both AppArmor and SELinux introduce some overhead that varies dependent on the work load and scenarios. Under macro benchmarks, the mediation overhead is often small or even within the margin of error (unmeasurable). In micro-benchmarks mediation overhead tends to be more pronounced but still small with a measurable overhead typically being <5%.

It is hard to give exact numbers for LSM performance impact as it depends on many factors

• The workload
• The number of profiles loaded
• The LSM and kernel version
• Even complexity of policies can affect performance to some degree, though AppArmor uses several techniques that help minimize this.

However, most micro-benchmarks and macro-benchmarks show that AppArmor introduces a lower overhead than SELinux (see Zhang et al. (2021), Table 7).

1) AppArmor policy generally crosses fewer LSM hooks than SELinux policy and therefore incurs less overhead. 2) Default AppArmor policy is generally less complex than default SELinux policy and therefore incurs less overhead.

- (see [Zhang et al. (2021)](https://dl.acm.org/doi/10.1145/3433210.3453078), Figure 6).
- (see [Miki et al. (2023)](https://doi.org/10.1109/CANDAR60563.2023.00029), TABLE X).
!!! warning "Dubious source"
    Miki paper seems *very* dubious, giving negative overhead for AppArmor, without any explanation and without acknowledging measurement uncertainty... This paper should probably be taken with a grain of salt.

3) AppArmor introduces less memory overhead than SELinux. - (see Miki et al. (2023), TABLE VI, overhead of 22% vs 85%).

Support for AppArmor and SELinux

Most distributions can run either with AppArmor or SELinux, but default LSM they use vary. It is generally recommended to use the distribution default, as it is better tested and supported. Therefore the choice of the LSM you want to use also depends on the distribution you want to use for your environment.

Standards

Both AppArmor and SELinux are compatible with most Security benchmarks and standards.

• The CIS (Center for Internet Security) recommends using either AppArmor or SELinux.

Conclusion

Both AppArmor and SELinux are excellent choices for Linux security. The choice between the two depends on your specific needs and environment.