Glossary
Reference definitions for key AppArmor and security concepts.
policy
A comprehensive set of rules defining what an application can or cannot do on the system. Policies encompass profiles, abstractions, and tunables that collectively confine a system.
See also: profile
profile
The specific file that contains the policy definition for a given application. Profiles allow defining what resources (files, network, capabilities, ...) a single program is allowed to access through fine-grained rules.
See also: policy
AppArmor
The Mandatory Access Control (MAC) LSM presented in this documentation. It actively protects the operating system and applications from external or internal threats by enforcing good behavior and mitigating exploits through profiles defining rules for applications. These policies are enforced by the kernel and cannot be disabled by users for security reasons. AppArmor is the default major LSM on some distributions including Ubuntu
LSM
Linux Security Module. A framework of hooks placed at critical points in the kernel (such as file access, task creation, or network operations) that allows the Linux kernel to support multiple computer security models. Major LSMs (like AppArmor or SELinux) enforce high-level, comprehensive security policies, while minor LSMs (like Capability or Yama) provide simpler, more specific security restrictions that can be stacked with major ones.
Profile Mode
The operational mode of an AppArmor profile. Profiles can run in Enforce mode (blocking restricted actions), Complain mode (allowing actions but logging violations), Kill mode (killing the restricted processes on violation), or Unconfined (no restrictions applied).
Rule
A single line in an AppArmor profile that governs a specific action. Rules can allow or deny access to most kernel resources, including files, networks, capabilities, and cross-process interactions. AppArmor rules are very fine-grained.
Abstraction
Reusable profile snippets that grant common permissions (like networking, DNS access, or standard library usage). Abstractions allow you to avoid writing the same rules in every profile, keeping them short and maintainable.
Tunable
Variables used to adjust AppArmor policies to match the local system environment without modifying the core profiles themselves (e.g., globally defining the @{HOME} directory path).
Profile Transition
When a confined application executes another program, the AppArmor profile can automatically transition the new process into a different target profile to restrict its execution context to the correct profile.
Object delegation
A mechanism to safely pass access rights over a specific resource (such as an open file descriptor) across profile boundaries, allowing a restricted process to temporarily grant access to another. The implementation of object delegation is currently partial
Audit rule
A rule modifier that forcibly logs the access event to the audit logs in system logs. This is notably useful for monitoring specific behaviors or debugging profiles.
See also: Allow rule, Deny rule
Deny rule
A rule explicitly rejecting an access attempt. Deny rules take precedence over allow rules and silently block the action (unless combined with audit).
See also: Allow rule, Audit rule
Allow rule
A rule explicitly granting permission to access a requested resource. In Enforce mode, any action that is not covered by an Allow rule is implicitly denied.
See also: Deny rule, Audit rule
Stacking
Applying multiple AppArmor profiles simultaneously to a single task or application. The effective permission is the intersection of all stacked profiles, ensuring that stacking can never be used to gain any privilege.
Policy Namespace
An isolated environment for loaded AppArmor profiles. Namespaces allow systems (like containers) to load their own overlapping profile names with differing policies without conflicting with the host system.
Profile Hat
A sub-profile used for application-directed transitions (e.g. using aa_change_hat). Hats are commonly used in web servers and application servers to rapidly isolate individual web requests without launching a new process.
Attachment path
A regex defined in a profile header defining for which path the profile is applied. It is possible to refer to that in profiles through the @{attach_path} variable.
See also: Exec path
Exec path
The specific file system path to the executable file being launched by a process. It is possible to refer to that in profiles through the @{exec_path} variable.
See also: Attachment path
attach_disconnected
A flag used to handle filesystem paths that are disconnected from the root filesystem. It allows AppArmor to safely mediate files that have no path representation (e.g. abstract socket, deleted files, ...)
ABI
Application Binary Interface. AppArmor features policy ABIs to ensure profile compatibility across different kernel parser versions, stabilizing how rules are interpreted over time.
Variable
A configuration value inside a profile (e.g., @{HOME}) that dynamically expands to lists of file paths or strings during compilation, making profiles highly portable.
DAC
Discretionary Access Control. The traditional UNIX/Linux file permissions system based on user and group ownership (e.g., chmod 755). It is evaluated before MAC controls like AppArmor.
See also: Access Control Model, MAC
MAC
Mandatory Access Control. System-wide policies enforced by the central kernel authority rather than the resource owner. AppArmor guarantees MAC restrictions even if the application runs as root.
See also: Access Control Model, DAC
RBAC
Role-Based Access Control. An access control model where rights are assigned to structural roles (like 'DB Admin') rather than individual users or processes. SELinux is often used to perform RBAC.
See also: Access Control Model