Is troubleshooting AppArmor with 'teardown' unsafe?

I understand there is a safer, more targeted way to troubleshoot AppArmor's possible contribution to an issue than completely stopping the service and tearing down AppArmor profiles. Can someone give me the details, and the advantages of the better approach?

Solution 1:

Here's what I was thinking of (from https://wiki.ubuntu.com/DebuggingApparmor ) -- "complain mode" . This doesn't address the issue of relative merits or consequences of this versus other debugging methods.

When debugging, it may also be useful to put apparmor into 'complain' mode. This will allow your application to function normally while apparmor reports accesses that are not in the profile. To enable 'complain' mode, use:

sudo aa-complain /path/to/bin

where '/path/to/bin' is the absolute path to the binary, as reported in the 'profile=...' portion of the 'audit' entry. Eg:

sudo aa-complain /usr/sbin/slapd

To re-enable enforcing mode, use 'aa-enforce' instead:

sudo aa-enforce /path/to/bin

To disable a profile:

sudo touch /etc/apparmor.d/disable/path.to.bin
sudo apparmor_parser -R /etc/apparmor.d/path.to.bin

When troubleshooting then, if there is something broken that appears to be related to a spooky permissions problem ('Hmm, looks like access control, but it's not a Unix permissions problem, or an NFS issue, or PAM issue, or a media mounting goof, etc. -- perhaps it's AppArmor.'), Kees Cook points out that best course of action is too check your system logs. Notably, per Kees Cook, "the output of dmesg will report all AppArmor denials, and will include the profile."