Mastering AppArmor: Path-Based Protection

In the previous lesson, we learned about the "Label-based" world of SELinux. Now, we move to the "Path-based" alternative preferred by Ubuntu, Debian, and SUSE: AppArmor.

AppArmor is generally considered "Easier" to understand than SELinux because its rules look like the file system you already know. Instead of worrying about invisible labels, you create a Profile for a program (like /usr/sbin/nginx) and list exactly which files and folders that program is allowed to touch.

If Nginx tries to read a file outside its list, AppArmor shuts it down instantly.

1. The States of a Profile

AppArmor works on a "Per-Program" basis. Each program can be in one of three states:

Enforce: The rules are active. Violations are Blocked and Logged.
Complain: The rules are inactive. Violations are Allowed but Logged (useful for testing new software).
Disabled: No rules exist for this program.

2. Managing Profiles with aa-tools

AppArmor profiles are stored in /etc/apparmor.d/. They are named after the path of the program (replacing / with .). For example, the profile for /usr/sbin/ntpd is named /etc/apparmor.d/usr.sbin.ntpd.

Common Commands:

# See a summary of active profiles
sudo aa-status

# Put a specific program into 'Complain' mode so it stops blocking
sudo aa-complain /usr/sbin/nginx

# Put it back into 'Enforce' mode for production
sudo aa-enforce /usr/sbin/nginx

# Reload all profiles after a change
sudo systemctl reload apparmor

3. Reading an AppArmor Profile

An AppArmor profile look like a refined list of permissions.

# Example snippet for a hypothetical app 'myapp'
/usr/bin/myapp {
  # Allow reading common libraries
  /lib/x86_64-linux-gnu/*.so  mr,
  
  # Allow reading config, but not writing
  /etc/myapp.conf             r,
  
  # Allow full access to its own data folder
  /var/lib/myapp/**           rw,
  
  # Block EVERYTHING else by default
}

Flags:

r: Read.
w: Write.
m: Memory Map (needed for shared libraries).
k: Locking.

4. Practical: Learning a New Profile

If you have a custom application and you want to build a security profile for it, you don't have to write it from scratch. You can use aa-genprof.

Run sudo aa-genprof /path/to/myapp.
Use your app normally (click buttons, save files). AppArmor records what the app tries to do.
Go back to the terminal and press "Scan". AppArmor will ask: "I saw it touch /etc/data. Allow?"
When finished, AppArmor generates the final profile for you.

5. Troubleshooting: The Log Trail

If an app is failing and you suspect AppArmor, search for "DENIED" in your system log.

# Find AppArmor rejections in real-time
sudo tail -f /var/log/syslog | grep -i apparmor

6. Example: An AppArmor Profile Auditor (Python)

If you are a security officer, you want to know which your critical apps are "Naked" (Running without a profile) or in "Complain" mode. Here is a Python script that parses aa-status to find gaps in your defense.

import subprocess

def audit_apparmor_status():
    """
    Groups running processes by their AppArmor enforcement level.
    """
    print("--- AppArmor Security Audit ---")
    print("-" * 35)
    
    try:
        res = subprocess.run(["sudo", "aa-status"], capture_output=True, text=True)
        content = res.stdout
        
        # Check Enforce mode
        enforce_count = content.count("enforce mode")
        complain_count = content.count("complain mode")
        unconfined_count = content.count("processes are unconfined")
        
        print(f"Profiles in ENFORCE:  {enforce_count}")
        print(f"Profiles in COMPLAIN: {complain_count}")
        
        if complain_count > 0:
            print("[WA] Warning: Some apps are in Complain mode (Security is log-only).")
            
        if unconfined_count > 0:
            print(f"[!!!] DANGER: {unconfined_count} processes are UNCONFINED (No protection).")
            
    except Exception as e:
        print(f"Error checking AppArmor: {e}")

if __name__ == "__main__":
    audit_apparmor_status()

7. Professional Tip: Use 'aa-logprof' for Updates

When you upgrade an application, it might try to touch new files it didn't use before. Instead of manually editing the profile, run sudo aa-logprof. It scans your logs for recent rejections and asks you if you want to update the profile to allow them.

8. Summary

AppArmor is the intuitive guardian of path-based systems.

Profiles are policies for specific executable paths.
Enforce vs Complain allows for safe development and testing.
aa-genprof automates the creation of security rules.
aa-status is your primary dashboard for security coverage.
Paths are the primary logic: if it's not in the path list, it's blocked.

In the next lesson, we will move from access control to "Evidence Detection": Intrusion Detection with AIDE.

Quiz Questions

Why is AppArmor considered easier for beginner sysadmins than SELinux?
What happens if a process in "Complain" mode tries to write to a forbidden file?
How do the flags r, w, and m differ in an AppArmor profile?

Continue to Lesson 4: Intrusion Detection—AIDE (Advanced Intrusion Detection Environment).

The Path-Based Guardian: Mastering AppArmor