Advanced Security: Intro to Mandatory Access Control

In all our previous lessons on permissions (Module 5), we learned about DAC (Discretionary Access Control).

• You own a file.
• You "discretionarily" decided who can read it.
• Root can read everything.

The Problem with DAC: If a hacker takes over your web server process (Nginx), and that process is running as root (or can escalate to root), the hacker now has access to your entire system. They can read your auth.log, steal your SSH keys, and delete your database.

The Solution: MAC (Mandatory Access Control).

In a MAC system, the Security Policy is set by the Administrator (The Law), and even Root must follow it. If the policy says "The Web Server can only read files in /var/www/html", then even if a hacker becomes root via a web server exploit, they cannot read /etc/shadow.

---

1. Discretionary (DAC) vs. Mandatory (MAC)

Feature	DAC (Standard Linux)	MAC (SELinux/AppArmor)
Who decides?	The owner of the file.	The System Security Policy.
Can Root bypass it?	YES.	NO.
Flexibility	High (anyone can chmod).	Strict (Only admins can change logic).
Safety	Good for users.	Essential for Internet-facing services.

---

2. The Two Heavyweights: SELinux and AppArmor

Linux has two main implementations of MAC. You usually only use one.

I. SELinux (Security-Enhanced Linux)

• Used by: Red Hat, CentOS, Fedora.
• Philosophy: "Label EVERYTHING." Every file, every process, and every network port has a "Label." If the process label doesn't match the file label, access is denied.
• Complexity: Very high (and very powerful).

II. AppArmor

• Used by: Ubuntu, Debian, SUSE.
• Philosophy: "Path-based Security." You create a "Profile" for a specific program (like /usr/sbin/nginx) and list exactly which folders it is allowed to touch.
• Complexity: Medium (easier for beginners).

---

3. The Logic of "Enforcing" vs "Complaining"

MAC systems can be intimidating. If you mess up the configuration, your web server will simply stop working. Because of this, both systems have a "Learning Mode."

• Enforcing: The security policy is active. Illegal actions are Blocked.
• Permissive / Complain: The security policy is inactive. Illegal actions are Allowed, but they are Logged so you can see what would have been blocked.

---

4. Practical: Checking your Shield Status

# Check if SELinux is active (Red Hat systems)
sestatus

# Check if AppArmor is active (Ubuntu systems)
sudo aa-status

---

5. Identifying a MAC Rejection

How do you know if a "Permission Denied" error is a standard DAC error or a MAC rejection? You check the security logs.

• SELinux errors are usually in /var/log/audit/audit.log (look for AVC).
• AppArmor errors are usually in /var/log/syslog (look for apparmor="DENIED").

---

6. Example: A MAC Conflict Detector (Python)

If you are troubleshooting a web server that won't start, use this Python script to check if a MAC system is the "Secret Killer" of your process.

import subprocess
import os

def check_mac_interference():
    """
    Looks for signs of MAC denials in the system logs.
    """
    print("--- Mandatory Access Control Audit ---")
    
    # 1. Check for AppArmor Denials (Common on Ubuntu)
    try:
        if os.path.exists("/var/log/syslog"):
            res = subprocess.run(["grep", "-i", "apparmor", "/var/log/syslog"], 
                                 capture_output=True, text=True)
            if "DENIED" in res.stdout:
                print("[!] ALERT: AppArmor has denied access to a process recently.")
                # Show the last denial for context
                print(f"    Latest: {res.stdout.splitlines()[-1]}")
    except Exception:
        pass

    # 2. Check for SELinux Denials (Common on RHEL)
    try:
        if os.path.exists("/var/log/audit/audit.log"):
            res = subprocess.run(["sudo", "grep", "AVC", "/var/log/audit/audit.log"], 
                                 capture_output=True, text=True)
            if "denied" in res.stdout:
                print("[!] ALERT: SELinux (AVC) has blocked a process.")
    except Exception:
        pass

if __name__ == "__main__":
    check_mac_interference()

---

7. Professional Tip: Don't Turn it Off!

The most common (and worst) advice on the internet for fixing a broken server is: setenforce 0 (Disable SELinux). This is like fixing a "Low Tire Pressure" light by cutting the wires to the sensor.

Always keep your MAC system in Permissive mode while troubleshooting, and then fix the policy rather than disabling the security.

---

8. Summary

MAC is the "High-Security" layer of Linux.

• DAC is the owner's discretion; MAC is the system's law.
• Root can be limited by a MAC policy.
• SELinux uses labels; AppArmor uses paths.
• Audit logs are where you find the evidence of a block.

In the next lesson, we will deep dive into the Red Hat standard: Mastering SELinux.

Quiz Questions

1. Why is DAC (standard permissions) not sufficient for a high-security server?
2. What is the difference between "Enforcing" and "Permissive" modes?
3. In which log file would you look for an AppArmor rejection message?

---

Continue to Lesson 2: The Red Hat Shield—Mastering SELinux.