Complain mode is an AppArmor learning state that records policy violations without blocking them. It helps administrators discover which resources an application needs before moving the profile into enforce mode, making policy tuning safer and less disruptive.
What Complain Mode Does in AppArmor
AppArmor complain mode is a permissive learning state. It logs denials that would have blocked activity in enforce mode, letting teams see what an application actually needs before tightening policy.
This makes complain mode useful when policy is still being tuned, but it also means the profile is not actively preventing access. Administrators should treat it as a discovery phase, not as a security end state.
How It Supports Policy Development
Complain mode helps turn real workload behaviour into policy evidence. By observing logged violations, teams can identify missing file paths, network calls, capabilities, or execution patterns that need to be allowed for normal operation.
That feedback loop is especially valuable for legacy applications, packaged software, and services with uncertain dependencies. It reduces the risk of moving too quickly into enforce mode and breaking production functionality with an incomplete profile.
Complain Mode Versus Enforce Mode
The difference between the two states is operationally important. In complain mode, AppArmor still evaluates policy, but it records violations rather than denying them. In enforce mode, those same violations become blocks.
Practically, that means complain mode can be used to stage policy changes, validate assumptions, and confirm whether a proposed rule set is accurate. It is also why complain mode should not be mistaken for a protected runtime state, because the application may still reach resources that the final policy will later restrict.
Common Uses and Limits
Teams often use complain mode during initial rollout, after application updates, or when debugging policy regressions. It is a good fit when you need telemetry about what would fail, but not when you need the control itself to stop access.
Its main limitation is that violations are tolerated during learning, so the mode depends on attentive review. If logs are ignored or the profile is never promoted, the system can remain in a semi-tuned but non-enforcing state for longer than intended.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | CM-7 — Least Functionality | AppArmor complain mode helps identify what an application truly needs before enforcing least functionality. |
| AC-3 — Access Enforcement | Enforce mode versus complain mode is a direct access-enforcement distinction in policy control. | |
| AU-2 — Event Logging | Complain mode depends on logged denials to reveal policy gaps during learning. | |
| Recommendation — Use CM-7 to remove unnecessary access and tighten the AppArmor profile after validation. Apply AC-3 to convert validated allow rules into enforced access restrictions. Configure AU-2 to retain denial events that inform AppArmor policy tuning. | ||
| ISO/IEC 27001:2022 | A.8.9 — Configuration management | AppArmor profile states are configuration choices that must be controlled during rollout and tuning. |
| Recommendation — Manage profile state changes under A.8.9 so learning and enforcement transitions are approved and traceable. | ||
