LSM Tools – AppArmor vs. SELinux and Their Key Differences - Part 4/7

If securing systems is a fortress, understanding the security models and frameworks is knowing who holds the keys and who defines the blueprints. You should know the LSM isn't just a framework; it's extensible via modules like AppArmor and SELinux, each offering unique approaches to Mandatory Access Control (MAC) security approach. But first of all, what's the functionality of this called "MAC"?

 

The Foundation: DAC vs. MAC

Traditional UNIX systems rely heavily on Discretionary Access Control (DAC). Under DAC, access hinges on user permissions (owner, group, other) coupled with corresponding permissions (read, write, execute). The inherent challenge with DAC is its name: access control is discretionary, meaning the secure state of the system relies heavily on the behavior and judgment of the users. So, users have the ability or discretion to modify permissions on their files, for instance, by running chmod via Linux Terminal. However, securing a Linux environment demands more than just these traditional user permissions. This is where MAC steps in, acting as an essential additional access control layer.

In a MAC-armed Linux system, access control is enforced by the operating system kernel and defined exclusively by centrally set policy rules. The key difference is that access controls are not left to the discretion of users. Users and processes cannot simply change the security rules or work around them. MAC minimizes the risk of unauthorized access and data breaches. This approach is vital in environments where sensitive data and critical operations are at stake. Now let's dive to the next part of the story: SELinux and AppArmor both are MAC-based security mechanisms.

 

Introducing SELinux: History and Core Concepts

The most well-known MAC implementation in the Linux ecosystem is Security-Enhanced Linux (SELinux), a robust and established system. SELinux was originally developed by NSA as a series of patches to the Linux kernel, leveraging the LSM framework. This technology is mature, having been released to the open-source community in 2000, and LSM itself has been a part of the Linux kernel since version 2.6 (released in December 2003). RedHat has been acknowledged as a leading corporate contributor to its development and the RedHat-based Linux systems are the most-compatible distros with SELinux.

SELinux significantly enhances security by implementing the principle of least privilege, confining applications so that their allowed activities are reduced to a minimal set. This confinement ensures that abnormal application behavior is detected and prevented, thus reducing the potential impact of exploits and vulnerabilities. This advanced security model is vital for safeguarding sensitive data in modern Linux environments against unauthorized access. Some major improvements for Linux systems are included:

1. SELinux effectively reduces related risks and threats.
2. Generating logs (with more details) for enhancing security insight (permissive mode) and future restriction improvements (enforcing mode). 
3. Better incident response and security remediation.

On the other hand, AppArmor is another Linux security framework that uses a MAC system to confine programs to a limited set of resources by applying security rules defined in profiles. By creating profiles that specify what files an application can access and what operations it can perform, AppArmor can protect the system from many risks and vulnerabilities. AppArmor is the default security framework in Debian, openSUSE and Ubuntu distros and Canonical is one of major distributors of this.

SELinux architecture:

The core functionality of SELinux rests upon two major concepts: labeling and Type Enforcement (TE).

1. Labeling (Security Contexts): Every subject(like process) and object/resource (such as files, ports, and network interfaces) is assigned a security context, or label, which identifies the resource to SELinux. For files and directories, this label is stored as an extended attribute on the file system. The context usually consists of four fields: the SELinux user, role, type (or domain), and optionally, the sensitivity level. The type field is generally the most important element used to distinguish objects in a typical policy.
2. Type Enforcement (TE): This mechanism attempts to specify exactly which components of the operating system a given application needs to interact with and the required level of access (e.g., read, write). SELinux policy rules dictate how an object operating in one context can interact with objects in other contexts. Critically, TE operates under a strict "default deny" posture: anything not specifically permitted by the SELinux policy is denied.

Security context is something like this: user:role:type:level. Policies are fine-grained, enforcing least-privilege via type enforcement (TE), role-based access control (RBAC), and multi-level security (MLS). It's powerful for complex environments but has a steep learning curve—policies can be thousands of lines, and troubleshooting involves tools like audit2allow. While the MLS is using both sensitivity levels (like Top Secret) and categories for access control, the MCS (Multi-Category Security) is a simplified version that uses only non-hierarchical categories, effectively setting the sensitivity level to s0. However, considering AppArmor doesn't support both of MCS/MLS, and generally is very user-friendly for desktops/servers, while takes a path-based approach, confining applications to specific file paths and capabilities (e.g., allowing /etc/passwd read but not write). BTW if the path has been changed maybe the security mechanism doesn't apply, while with cost of complexity in SELinux, it will never happened because of the mentioned Labeling mechanism. So it's like a best practice (NOT rule) to use SELinux for high-security Servers (e.g., government), and AppArmor for general purposes (e.g., Ubuntu servers). Caring about these tools via LSM means tailored, enforceable security without reinventing the wheel.

 

SELinux vs. AppArmor: Key Characteristics

While SELinux and AppArmor are both LSMs that provide MAC functionality, they employ fundamentally different security models, leading to significant differences in management, complexity, and granularity.

 

 

Feature	SELinux	AppArmor
Security Model	Label-based access control. Rules are assigned to security contexts and object labels. The security context is retained even if the file is moved or remounted.	Path-based access control. Rules are assigned directly to file paths. If a file is moved, access controls may behave differently as the system looks at the path, not the context.
Granularity & Control	Offers highly granular and fine-grained mandatory access control with detailed rules on users, processes, and objects. It supports roles, users, and multi-level security (MLS/MCS).	Provides a good level of control but lacks the depth of multi-level and role-based enforcement found in SELinux.
Complexity & Learning Curve	Steep learning curve. It is complex to configure and manage, requiring detailed policy management an‍طd specialized tools.	Simpler and easier to configure and manage. Profiles are simpler to write and debug, making it ideal for beginners.
Flexibility	Highly flexible for complex or dynamic environments. Allows for the creation of custom roles, users, and types.	More static; better suited for predefined application behavior.
Target Environment	Preferred for enterprise and high-security environments due to its strict isolation and scalability.	Recommended for desktops and servers where ease of management is a priority.
Troubleshooting & Logging	Logs are voluminous and harder to interpret, often requiring specialized utilities like audit2allow or semanage.	Easier to troubleshoot due to human-readable, plain-text profiles and readable logs.

 

Conclusion:

In essence, SELinux's choice of a label-based model ensures that the security context of a resource reveals its purpose and remains intact regardless of its location or filename, providing a layer of robust containment and isolation far exceeding the capabilities of DAC and generally providing greater depth than path-based MAC systems like AppArmor. Although there is a lot of useful information about the SELinux & AppArmor, (and maybe other LSM like Smack, Yama, and Tomoyo) how to work with them and practical use cases, there is not enough space to cover them in this post, and I will talk about each of them separately in the future.