You spend all afternoon crafting a perfect AppArmor profile for your new Go binary, pinning it down to just the directories it needs. You run it, it works, and you move on. Then, a week later, you update the deployment path or move a data directory, and the whole service starts dying with Permission Denied errors that show up in your kernel logs but tell you absolutely nothing about the actual policy violation.

Why you shouldn’t just disable it to debug

The gut reaction is to set the profile to complain mode just to get it running again. But that’s a trap. If you let it run in complain mode, you might ignore subtle regressions where the process touches things it shouldn’t be near anymore. Instead, you need to be surgical with your audit logs, specifically using the aa-decode tool to actually make sense of the noise the kernel dumps into dmesg.

dmesg | grep 'audit: type=1400' | aa-decode

• Check /sys/kernel/security/apparmor/profiles to see which tasks are actually loaded
• Use aa-status to confirm your profile is enforcing and not just sitting there watching
• Keep your profiles in /etc/apparmor.d/local/ to avoid them getting overwritten on package updates

Most tutorials tell you to use the wizard-like automation tools, but those often generate profiles that are way too permissive. Write them by hand, use strict absolute paths, and when you finally move your binaries to a production path, check the logs immediately. If you’re not seeing logs, verify your audit daemon is actually capturing the denials, because AppArmor will silently fail your process while your logs stare back at you empty.