Dear Maintainer,

As discussed in #872726 (wontfix) already in 2017, "ausearch -m avc"
does not find any AVC messages generated by AppArmor. For a long time
I thought it simply is not even meant to support anything else except
SELinux, but it turns out that is is simply a disagreement between the
kernel LSM and audit userspace tools on what event ID numbers should
AppArmor use (1400 vs 15xx). So the events are in the audit.log, but
ausearch simply ignores them due to parsing errors.

This issue was tracked in Ubuntu for over 10 year:
https://bugs.launchpad.net/ubuntu/+source/audit/+bug/1117804

and recently finally fixed with a simple patch:
https://launchpadlibrarian.net/869061395/lp1117804-resolute-3.debdiff

Please consider applying the patch to Debian audit package as well.
Although this may be an inelegant workaround, it should not cause any
harm, and a proper resolution could take considerable time. It would
be fairly important (for security!) to support using the ausearch and
aureport tools with AppArmor, which is, after all, Debian’s default
MAC/LSM.

Thanks.

Upstream bug report was closed as wontfix in Feb 2024:
https://github.com/linux-audit/audit-userspace/issues/351

I suppose it is technically accurate to say that "AVC" (Access Vector
Cache) is traditionally SELinux-specific terminology. AppArmor and other
MAC LSMs presumably employ some form of caching as well, although I am
unsure whether referring to it as "AVC" would be incorrect. In any
event, this is how AppArmor currently operates and has operated for a
long time; changing it now could break a substantial number of custom
tools that analyze audit logs in sites using AA.

ausearch/aureport currently have no AppArmor-specific equivalent of
"--avc", and introducing a different option for each LSM seems like poor
UX to me. It's a weird quirk to use that term to mean policy decision
audit entries anyway, isn't the cache just an internal optimization
detail?

It does not seem to me that the upstream project is very interested in
supporting other than SELinux.

Hello,

Well I'm not planning to keep a patch forever in the debian package,
while from my understanding the issue is in apparmor/kernel.

I still didn't get an answer on why apparmor cannot change the event ID
to the one that were assigned to them. This is something that is known
for years (10y+) and nothing was done on the apparmor side.

So this, for me, is a WONTFIX again.

Kind regards,
Laurent Bigonville

FTR: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=872726