Comment 1 for bug 770671

AppArmor could indeed use better auditing controls, and several improvements are on the road map. There is however a feature that you can use today that might help.

AppArmor allows for deny rules, that record in a profile that a specific is expected and should be denied. This provides the tools a way to remember what accesses have been explicitly denied in the past. It also quiets the logging of any access that matches the deny rule.

  Eg.
    deny /etc/password w,

  would quiet logging of write accesses to /etc/password but not read accesses.

If you need/want denied rule to be logged it can have the audit keyword prepended.
  audit deny /etc/password w,

In this case the deny rule only serves as a hint to the profile learning tools that this access has been logged before and explicitly denied, so that the tools do not ask about log entries that match.

Deny rules have one more property that you must be aware of, they subtract permissions from the allow set
  deny /etc/password w,
  /etc/** rw,

would allow read, write access to all file in /etc/ except /etc/password which will only have read access because write access has been denied. You can think of this as all the permissions for allow rules are accumulated in one set and all the permissions associated with deny rules are accumulated in a second set, and then the deny set is subtracted from the allow set.

Deny rules work with globbing
   deny /etc/** w,

and also with network and capability rules.