Everyone loves AppArmor because it feels simpler than SELinux, but that simplicity often masks a dangerous reality. I have seen countless production setups where an application is supposedly confined, yet it is happily writing to parts of the filesystem it should not even be able to see. You set the profile, restart the service, and assume you are safe. But if you are not checking the actual enforcement mode, you are just running with training wheels that fell off miles ago.

Stop trusting the status display

The standard status tools often lie to you. They tell you the profile is loaded, but they don’t explicitly warn you when your system is in a hybrid mode where some rules are ignored or degraded. You need to verify that your critical services are actually enforcing their constraints. If you are stuck in complain mode, the kernel is logging your failures but letting the attacker proceed. That is exactly how a small misconfiguration turns into a full system compromise during a breach.

aa-status | grep -E 'confinement|complain'

• If the output shows complain mode, your security is currently just a logging service
• Check /sys/kernel/security/apparmor/profiles for the true list of active loaded policies
• Verify your specific PID has the expected label in /proc/self/attr/current before you call it a day

Don’t just rely on the defaults. If you have an application that requires access to a sensitive socket, you should explicitly write the rule rather than widening the entire profile to account for it. Most people just set the profile to complain mode, trigger the violation, and copy the auto-generated suggestions. That is a quick way to ship a bloated, overly permissive profile that gives attackers exactly the path they need. Take ten minutes to trim those rules manually; your future self will thank you when the audit logs finally stay quiet.