All AppArmor Profiles are in enforce or complain mode
Verifies AppArmor has profiles loaded (in enforce or complain mode) rather than none, so policies are at least active and observable.
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
Loaded profiles, whether enforcing or complaining, mean the AppArmor policy is actually applied to running programs. If profiles exist on disk but none are loaded, the mandatory access control is dormant and provides no benefit. This rule is the baseline that confinement is active; a stricter companion rule (misc-all-apparmor-profiles-enforced) then requires enforce mode.
What Pavois checks
Pavois parses aa-status output for the profiles are loaded line, confirming the kernel has at least one AppArmor profile loaded. Reading the live aa-status reflects the effective runtime state, unlike inspecting /etc/apparmor.d/ files which only proves profiles exist on disk, not that they were applied.
describe command('aa-status 2>/dev/null | grep -qi \'profiles are loaded\' && echo ok || echo ko') do
its('stdout.strip') { should eq 'ok' }
endHow to verify it is applied
Run aa-status. Expect a line like NN profiles are loaded with NN > 0, and a non-zero count under enforce and/or complain mode.
Inspect & investigate
AppArmor activity is logged via the kernel audit subsystem in /var/log/audit/audit.log (entries tagged apparmor=) or in journalctl -k / /var/log/kern.log. The loaded-profile inventory and modes come from aa-status.
Remediation
No automated harden plan ships for this rule; apply it manually. Ensure the apparmor package and the profile packages (e.g. apparmor-profiles) are installed, that AppArmor is enabled at boot (systemctl enable --now apparmor), and load profiles with apparmor_parser -r /etc/apparmor.d/* (or aa-enforce/aa-complain per profile).
Pavois applies this with its own harden engine, the plan below, not a shell script:
| command | aa-status | sed -n '1,20p' # set profiles to enforce: aa-enforce /etc/apparmor.d/* (watch for app breakage, then aa-complain any that misbehave) |
|---|---|
| reason | forcing all profiles to enforce can break apps with incomplete profiles, review |
| resource | manual |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
Loading profiles in complain mode is low-risk because complain only logs, it does not block, a safe first step on a system that has never used AppArmor. The risk appears when a loaded profile is in enforce mode and too restrictive (see misc-all-apparmor-profiles-enforced). To stage safely, load profiles in complain mode first, watch /var/log/audit/audit.log for would-be denials, refine, then move to enforce.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| CIS | 1.3.1.3 | direct | per OS, see the benchmark table | 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.