AppArmor Mandatory Access Control

Overview

• What you will learn: The difference between Mandatory Access Control (MAC) and Discretionary Access Control (DAC), how AppArmor profiles confine applications, enforce versus complain modes, creating profiles with aa-genprof and aa-logprof, managing profiles with aa-status and aa-enforce, and troubleshooting AppArmor denials in audit logs.
• Prerequisites: Lesson 47 (OpenSSH Server and Client), familiarity with Linux file permissions and process management
• Estimated reading time: 25 minutes

Introduction

Traditional Linux file permissions follow a Discretionary Access Control (DAC) model: the owner of a file decides who can read, write, or execute it. While DAC is flexible, it has a fundamental weakness — if an attacker compromises a process running as a particular user, they inherit all the permissions of that user. A web server running as www-data can access every file that www-data owns, not just the files it actually needs.

Mandatory Access Control (MAC) adds a second, independent layer of access decisions enforced by the kernel. Under MAC, a security policy defines exactly which files, directories, network sockets, and capabilities each program may use. Even if an attacker gains control of a process, the MAC policy prevents the process from accessing anything outside its defined profile.

AppArmor is the MAC framework integrated into Ubuntu. It uses path-based profiles that are simpler to write and maintain than SELinux policies. In this lesson you will learn how AppArmor works, how to interpret and create profiles, and how to troubleshoot access denials.

MAC vs DAC

Discretionary Access Control (DAC)

In the DAC model, resource owners set permissions. The kernel checks the user ID and group ID of the calling process against the file’s permission bits. Superuser (root) bypasses all DAC checks. This means a single compromised root process has unrestricted access to the entire system.

Mandatory Access Control (MAC)

MAC policies are defined by the system administrator and enforced by the kernel regardless of file ownership. Even root-owned processes are confined. AppArmor implements MAC by associating a profile with each confined program. The profile lists every resource the program is allowed to access.

# Compare: DAC allows www-data to read anything it owns
$ ls -la /var/www/html/index.html
-rw-r--r-- 1 www-data www-data 612 Jan 10 09:00 /var/www/html/index.html

# MAC (AppArmor) additionally restricts nginx to only specific paths
# even though www-data owns many other files on the system

AppArmor Architecture and Profiles

AppArmor is compiled into the Ubuntu kernel as a Linux Security Module (LSM). When a program starts, the kernel checks whether an AppArmor profile exists for that executable path. If a profile is loaded, every file open, network connection, and capability request is checked against the profile rules.

Profile Location and Structure

# Profiles are stored in /etc/apparmor.d/
$ ls /etc/apparmor.d/
usr.sbin.nginx  usr.sbin.mysqld  usr.bin.man  ...

# A simplified profile for nginx
# /etc/apparmor.d/usr.sbin.nginx
#include <tunables/global>

/usr/sbin/nginx {
  #include <abstractions/base>
  #include <abstractions/nameservice>

  # Binary
  /usr/sbin/nginx          mr,

  # Configuration
  /etc/nginx/**            r,

  # Web content
  /var/www/html/**          r,

  # Logs
  /var/log/nginx/*          w,

  # PID and socket
  /run/nginx.pid            rw,
  /run/nginx/*.sock         rw,

  # Network
  network inet stream,
  network inet6 stream,

  # Capabilities
  capability net_bind_service,
  capability setuid,
  capability setgid,
}

Permission Flags

AppArmor uses single-letter flags to specify access types:

• r — read
• w — write
• m — memory map executable
• k — file locking
• l — link
• ix — inherit execute (child inherits parent profile)
• px — discrete profile execute (child runs under its own profile)
• ux — unconfined execute (child runs without a profile)

Enforce and Complain Modes

Every loaded AppArmor profile operates in one of two modes:

• Enforce mode: The kernel blocks and logs any access that violates the profile. This is the production mode.
• Complain mode: The kernel allows all access but logs violations. Use this mode when developing or debugging a profile.

# Check the status of all profiles
$ sudo aa-status
apparmor module is loaded.
48 profiles are loaded.
42 profiles are in enforce mode.
6 profiles are in complain mode.

# Switch a profile to complain mode
$ sudo aa-complain /usr/sbin/nginx

# Switch a profile to enforce mode
$ sudo aa-enforce /usr/sbin/nginx

# Disable a profile entirely
$ sudo aa-disable /usr/sbin/nginx

# Re-enable and reload
$ sudo apparmor_parser -r /etc/apparmor.d/usr.sbin.nginx

Creating Profiles with aa-genprof and aa-logprof

Writing a profile from scratch is tedious. AppArmor provides two tools that generate profiles by observing actual program behavior.

aa-genprof — Generate a New Profile

The aa-genprof tool creates a new profile by putting the target in complain mode, asking you to exercise the application, then scanning the logs for access patterns.

# Step 1: Start profile generation
$ sudo aa-genprof /usr/sbin/nginx

# The tool prompts you:
# "Please start the application to be profiled in another window
#  and exercise its functionality now."

# Step 2: In another terminal, exercise the application
$ sudo systemctl restart nginx
$ curl http://localhost/
$ curl http://localhost/nonexistent

# Step 3: Return to aa-genprof and press S to scan logs
# The tool shows each access and asks you to Allow, Deny, or Glob
# (A)llow  (D)eny  (G)lob  (N)ew  ...

# Step 4: Press S to save when done
# The profile is written to /etc/apparmor.d/

aa-logprof — Refine an Existing Profile

# After running the app in complain mode and generating log entries:
$ sudo aa-logprof

# aa-logprof scans /var/log/syslog (or audit.log) for AppArmor events
# and presents each new access for you to allow or deny

# This iterative process lets you progressively tighten the profile

Troubleshooting AppArmor Denials

When AppArmor blocks an access in enforce mode, it writes a denial message to the system log. Understanding these messages is key to fixing application issues caused by overly restrictive profiles.

# Search for AppArmor denials in syslog
$ sudo grep "apparmor="DENIED"" /var/log/syslog

# Example denial message:
# apparmor="DENIED" operation="open" profile="/usr/sbin/nginx"
#   name="/etc/ssl/private/server.key" pid=1234 comm="nginx"
#   requested_mask="r" denied_mask="r"

# Fix: Add the missing rule to the profile
# /etc/apparmor.d/usr.sbin.nginx
#   /etc/ssl/private/server.key  r,

# Reload the profile
$ sudo apparmor_parser -r /etc/apparmor.d/usr.sbin.nginx

# Use aa-logprof for guided fixes
$ sudo aa-logprof

Common Troubleshooting Commands

# List all loaded profiles and their modes
$ sudo aa-status

# Check if a specific process is confined
$ sudo aa-status | grep nginx

# View profile in parsed form
$ sudo apparmor_parser -p /etc/apparmor.d/usr.sbin.nginx

# Test a profile without loading it
$ sudo apparmor_parser -d /etc/apparmor.d/usr.sbin.nginx

# Force-reload all profiles
$ sudo systemctl reload apparmor

Key Takeaways

• DAC relies on file ownership and permission bits; MAC (AppArmor) adds kernel-enforced policies that confine each program to a defined set of resources regardless of user identity.
• AppArmor profiles are path-based text files stored in /etc/apparmor.d/ that specify which files, network access, and capabilities a program may use.
• Enforce mode blocks and logs violations; complain mode only logs them — use complain mode during profile development.
• Use aa-genprof to generate new profiles by observing application behavior, and aa-logprof to iteratively refine existing profiles from log data.
• Troubleshoot denials by searching for apparmor="DENIED" in syslog and adding the missing rules to the profile.

What’s Next

In the next lesson you will learn about Kerberos Authentication — how the Kerberos protocol provides network-wide single sign-on through ticket-based authentication, and how to deploy a Key Distribution Center on Ubuntu.

# 設定檔存儲在 /etc/apparmor.d/
$ ls /etc/apparmor.d/

# 權限旗標：r（讀取）、w（寫入）、m（記憶體映射執行）
# k（檔案鎖定）、l（連結）、ix/px/ux（執行模式）

# 檢查所有設定檔的狀態
$ sudo aa-status

# 切換到投訴模式
$ sudo aa-complain /usr/sbin/nginx

# 切換到強制模式
$ sudo aa-enforce /usr/sbin/nginx

# 停用設定檔
$ sudo aa-disable /usr/sbin/nginx

# 開始設定檔生成
$ sudo aa-genprof /usr/sbin/nginx

# 在另一個終端中執行應用程式
$ sudo systemctl restart nginx
$ curl http://localhost/

# 返回 aa-genprof 並按 S 掃描日誌
# 完成後按 S 儲存

# 在 syslog 中搜尋 AppArmor 拒絕
$ sudo grep "apparmor="DENIED"" /var/log/syslog

# 修復：將缺少的規則添加到設定檔
# 重新載入設定檔
$ sudo apparmor_parser -r /etc/apparmor.d/usr.sbin.nginx

# 使用 aa-logprof 進行引導式修復
$ sudo aa-logprof

# プロファイルは /etc/apparmor.d/ に保存
$ ls /etc/apparmor.d/

# 権限フラグ：r（読み取り）、w（書き込み）、m（メモリマップ実行）
# k（ファイルロック）、l（リンク）、ix/px/ux（実行モード）

# すべてのプロファイルのステータスを確認
$ sudo aa-status

# 苦情モードに切り替え
$ sudo aa-complain /usr/sbin/nginx

# 強制モードに切り替え
$ sudo aa-enforce /usr/sbin/nginx

# プロファイルを無効化
$ sudo aa-disable /usr/sbin/nginx

# プロファイル生成を開始
$ sudo aa-genprof /usr/sbin/nginx

# 別のターミナルでアプリケーションを実行
$ sudo systemctl restart nginx
$ curl http://localhost/

# aa-genprof に戻り S を押してログをスキャン
# 完了したら S を押して保存

# syslog で AppArmor 拒否を検索
$ sudo grep "apparmor="DENIED"" /var/log/syslog

# 修正：不足しているルールをプロファイルに追加
# プロファイルのリロード
$ sudo apparmor_parser -r /etc/apparmor.d/usr.sbin.nginx

# ガイド付き修正に aa-logprof を使用
$ sudo aa-logprof