Hello! Welcome to your next lesson in our "System Security and Hardening" module.
In our previous lessons, we focused on securing the perimeter of your system. We used firewalld to build a barrier against unwanted network traffic and nmap to probe that barrier from the outside, ensuring it was configured correctly. Now, we're going to shift our focus from the perimeter to the heart of the system itself. What happens if a service, like a web server, is compromised despite our firewall? How can we limit the damage an attacker can do once they have a foothold?
This lesson will address the learning outcome: Explain the concepts of Mandatory Access Control (MAC) and the roles of SELinux/AppArmor. We'll explore a powerful security model that adds a crucial layer of defense inside the operating system, creating strict rules that even the root user cannot easily bypass.
1. Beyond Traditional Permissions: What is Mandatory Access Control?
As a Linux user, you're familiar with the standard permission model of read, write, and execute for users, groups, and others. This model is known as Discretionary Access Control (DAC) because the "discretion" to set permissions lies with the owner of the file. If you own a file, you can grant access to anyone.
This is flexible, but it has a significant weakness: if a user or a program running as that user is compromised, the attacker gains all of their privileges. For example, a vulnerability in a web server running as the apache user could allow an attacker to read any file the apache user can read.
Mandatory Access Control (MAC) solves this problem by adding another layer of security. With MAC, access decisions are enforced by the operating system based on a system-wide policy that users cannot change. A process's access to a resource (like a file) depends on security labels or rules, not just user ownership and permissions.
Securing Linux with Mandatory Access Controls
To understand the fundamental difference between these two security models, let's start with a clear definition of MAC and how it contrasts with the DAC model you already know.
Please read the first two sections of this article from GeeksforGeeks, starting from 'Securing Linux with Mandatory Access Controls' and ending just before 'Types of MAC Systems'. Focus on the definition of MAC and its key features.
In essence:
- DAC (Discretionary Access Control): "I own this file, so I decide who gets to read it." This is the standard Linux permission system (
chmod,chown). - MAC (Mandatory Access Control): "The system policy says that a web server process can never access files in user home directories, period." This rule is mandatory and enforced by the kernel, even if file permissions would otherwise allow it.
This approach provides defense-in-depth. Even if an application is compromised, MAC can confine it, preventing it from accessing parts of the system it has no business touching.
2. The Linux Security Module (LSM) Framework
The Linux kernel doesn't have just one MAC system built-in. Instead, it provides a generic framework called Linux Security Modules (LSM). LSM inserts "hooks" into the kernel at critical points where system calls are made to access resources like files or memory. A security module, like SELinux or AppArmor, can plug into this framework to inspect these access attempts and deny them if they violate the security policy.
Overview of SELinux and AppArmor
This video from SUSECON gives a great high-level overview of the LSM framework and what Mandatory Access Control is in the context of the Linux kernel.
Watch from 02:14 to 03:02 to understand the role of the LSM framework, and then from 07:56 to 09:51 to see how MAC is defined and implemented via kernel 'hooks'.
Think of the LSM framework as a set of standardized ports in the kernel, and security modules like SELinux or AppArmor are the devices you can plug into those ports to enforce a security policy. A system can typically only have one major MAC module active at a time.
Now, let's look at the two most prominent MAC implementations on Linux.
3. SELinux: The Label-Based Approach
Security-Enhanced Linux (SELinux) was originally developed by the US National Security Agency (NSA) and is the default MAC system in Red Hat-based distributions like RHEL, CentOS, and Fedora.
SELinux works by assigning a security label, known as a context, to every single file, process, and port on the system. The SELinux policy consists of a massive set of rules that define how contexts can interact. For example, a rule might state that a process with the httpd_t (web server type) context can read files with the httpd_sys_content_t (web content type) context, but cannot write to them.
I Hate SELinux. You Can Too. (Linux+ Objective 2.5.1)
The video 'I Hate SELinux' from Shawn Powers does an excellent job of explaining the core concepts of SELinux in a practical way. Don't let the title fool you; it's a very clear and useful explanation for the Linux+ exam.
Please watch these three segments: 00:00 - 01:23: For an introduction to what SELinux is and the problem it solves. 07:03 - 09:20: To understand the structure of an SELinux context (user:role:type) and how to view it with ls -Z. Pay special attention to the 'type' field. 12:30 - 15:58: To see a classic, practical example of how moving a file (mv) versus copying a file (cp) affects its context, leading to 'Permission Denied' errors. This perfectly illustrates why contexts are so important.
SELinux Concepts
- Contexts: The security label (e.g.,
system_u:object_r:httpd_sys_content_t:s0). The most important part for day-to-day administration is the type (httpd_sys_content_t). - Labeling: When you move a file, it keeps its original context. When you copy a file, the new file inherits the context of the destination directory. This is a common source of SELinux issues.
- Modes: SELinux can run in three modes:
- Enforcing: The default mode. SELinux actively blocks actions that violate policy.
- Permissive: SELinux does not block actions, but it logs any violations. This is useful for troubleshooting.
- Disabled: SELinux is turned off completely (requires a reboot).
4. AppArmor: The Path-Based Approach
AppArmor (Application Armor) is the default MAC system in Debian-based distributions (like Ubuntu) and SUSE. Its approach is different from SELinux.
Instead of labeling every object on the system, AppArmor focuses on confining individual applications. It uses profiles, which are simple text files that define which files and capabilities a specific program is allowed to access. These rules are based on file paths (e.g., /var/www/html/*).
This path-based approach is generally considered simpler and easier to learn than SELinux's comprehensive labeling system.
Securing Linux with Mandatory Access Controls
The 'Securing Linux with Mandatory Access Controls' article from GeeksforGeeks also provides a good overview of AppArmor.
Read the section titled 'AppArmor Overview and Configurations'. Focus on understanding its path-based nature, profiles, and modes.
AppArmor Concepts
- Profiles: A set of rules applied to a specific executable file (e.g.,
/usr/sbin/nginx). - Path-Based: Rules specify what file paths an application can access (e.g.,
owner /var/log/nginx/*.log rw,). - Modes: AppArmor profiles can also be in different modes:
- Enforce: The default. The kernel enforces the profile's rules.
- Complain: Similar to SELinux's permissive mode. AppArmor logs policy violations but does not block them.
5. SELinux vs. AppArmor: A Comparison
For the Linux+ exam, it's important to know the key differences between these two systems.
Overview of SELinux and AppArmor
The SUSECON video provides a direct and detailed comparison of the two systems, including their core philosophies.
Watch from 09:51 to 15:00 for a side-by-side comparison table, and then from 15:45 to 18:26 for an excellent analogy that explains their different 'deny everything' vs. 'allow everything' default stances.
Here is a summary of the main differences:
| Feature | SELinux | AppArmor |
|---|---|---|
| Control Mechanism | Label-based. Every file and process has a security context. | Path-based. Rules are tied to the executable's file path. |
| Complexity | High. Steeper learning curve due to the comprehensive labeling system. | Lower. Generally easier to learn and write profiles. |
| Scope | System-wide. Policies cover all interactions on the entire system. | Application-focused. Confines specific programs listed in profiles. |
| Policy Format | Policies are compiled into a binary format and loaded into the kernel. | Profiles are plain text files, which are easier to read and edit. |
| Typical Distributions | Red Hat, Fedora, CentOS, Android | Ubuntu, Debian, SUSE |
| Core Philosophy | Deny by default at a system level. Extremely restrictive. | Allow by default at a system level, but individual applications are denied by default within their profile. |
Test your understanding!
You are troubleshooting a web application on a new server. You find that the web server process is being blocked from reading its own configuration file, even though the file has the correct user/group ownership and rw- permissions.
Based on this scenario, which MAC system is more likely to be the cause if the issue is that the configuration file was recently moved from a non-standard directory?
Show answer
SELinux is the more likely culprit. Because SELinux is label-based, moving a file (mv) preserves its original security context (label). If the file was moved from a directory like /tmp, it would retain a context that the web server process is not allowed to read, regardless of standard file permissions. AppArmor, being path-based, is less likely to cause this specific issue, as its rules typically depend on the file's final location (/etc/nginx/...), not its previous one.
Conclusion
You now have a conceptual understanding of Mandatory Access Control and its two major implementations in the Linux world. This added layer of security is a powerful tool for system hardening and is a key topic for the Linux+ exam.
Key Takeaways:
- Mandatory Access Control (MAC) is a security model where the system kernel enforces access policies, which cannot be overridden by users. This contrasts with Discretionary Access Control (DAC), the standard Linux permission model.
- SELinux is a label-based MAC system. It attaches a security context to every object and uses a system-wide policy to control interactions. It is common on Red Hat-based systems.
- AppArmor is a path-based MAC system. It uses profiles to confine specific applications based on the file paths they are allowed to access. It is common on Debian and SUSE systems.
- The primary role of both is to confine processes and limit the damage that can be done by a compromised application.
Preview of the Next Lesson:
Understanding the concepts is the first step. However, both SELinux and AppArmor are notorious for causing "permission denied" errors that can confuse administrators. In our next lesson, we will get practical and learn how to check SELinux/AppArmor status and interpret policy denial logs for troubleshooting. This will give you the skills to diagnose and begin to solve problems caused by these powerful security systems.