Ensure AppArmor is Active and Configured
Confirms the AppArmor kernel module is loaded and active, the prerequisite for any profile-based confinement.
Checked against the resolved running state (e.g. sshd -T, sysctl, systemctl show), catches drop-ins and Includes a file read would miss. Caveat: runtime ≠ persistence; a value correct now may not survive a reboot.
Pavois asserts the effective configuration, the live, resolved state, not a file. File-based scanners (OVAL/SCAP, Lynis) miss Includes, drop-ins and runtime defaults; this check sees what is actually applied.
A mapping is a cross-reference to where each standard places this requirement, anchored and cross-validated, not a claim of equivalence. A passing check is evidence toward these references, how to read it.
Why this rule matters
AppArmor implements mandatory access control: it restricts each confined program to an explicit allow-list of files, capabilities and network access, acting as a software whitelist that limits the blast radius of a compromised or vulnerable program. None of that applies if the AppArmor module is not even loaded, the entire MAC layer is then absent, leaving only standard discretionary permissions.
What Pavois checks
Pavois checks aa-status for module is loaded, confirming the LSM is active in the running kernel. This queries the live kernel state rather than assuming the package is installed or trusting a config file, so it catches the case where AppArmor was disabled on the kernel command line or never started.
describe command('aa-status 2>/dev/null | grep -qi \'module is loaded\' && echo ok || echo ko') do
its('stdout.strip') { should eq 'ok' }
endHow to verify it is applied
Run aa-status (or aa-enabled). Expect apparmor module is loaded. Cross-check with systemctl is-active apparmor (should be active) and cat /sys/module/apparmor/parameters/enabled (should be Y).
Inspect & investigate
Module load and AppArmor events appear in the kernel log (journalctl -k / /var/log/kern.log) and policy decisions in /var/log/audit/audit.log (entries tagged apparmor=). Service state comes from systemctl status apparmor.
Remediation
No automated harden plan ships for this rule; apply it manually. Install AppArmor (apt install apparmor apparmor-utils), enable the service (systemctl enable --now apparmor), and ensure it is not disabled on the kernel command line, remove any apparmor=0/security= override from GRUB (/etc/default/grub), run update-grub, and reboot so the module loads at boot.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| command | apt-get install -y apparmor apparmor-utils # ensure the bootloader passes apparmor=1 security=apparmor (pavois's kernel-cmdline controls do this), systemctl enable --now apparmor # then REBOOT for the cmdline to take effect, and: aa-enforce /etc/apparmor.d/* |
|---|---|
| reason | enabling AppArmor needs a kernel cmdline change + reboot, do it deliberately |
| resource | manual |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
Merely loading the AppArmor module is non-disruptive on its own; impact comes from the profiles it then enforces. If you enable AppArmor and the distribution's profiles are in enforce mode, confined services (e.g. MySQL, cups, man) may be restricted, review their profiles and /var/log/audit/audit.log first. Enabling AppArmor requires a reboot only if it was disabled on the kernel command line. Note AppArmor and SELinux are mutually exclusive; do not enable both.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| ANSSI BP-028 | R45 | direct | 2.0 | high |
| NIST | AC-3(4), AC-6(8), AC-6(10), CM-7(5)(b), CM-7(2), SC-7(21), CM-6(a) | supporting | 800-53 Rev 5 · 800-171 Rev 2 (pinned) | medium |
| DISA STIG | UBTU-22-431015, UBTU-24-100510 | direct | per OS STIG release | high |
Each reference is a cross-reference anchored in the upstream benchmark and cross-validated against the SCAP Security Guide and ansible-lockdown, not a claim of equivalence. Direct = a prescriptive, line-level requirement; supporting = an abstract control family (NIST) the check provides evidence toward. How to read a mapping.