ausearch doesn't show AppArmor denial messages

This bug is, I think, currently discussed on the linux-audit mailinglist:

https://www.redhat.com/archives/linux-audit/2014-May/msg00094.html

I have asked about it in audit mailing list [0], and Audit developer said that AppArmor should use assigned event numbers in right way, or something like that..

[0] https://www.redhat.com/archives/linux-audit/2016-April/msg00129.html

This bug is missing log files that will aid in diagnosing the problem. While running an Ubuntu kernel (not a mainline or third-party kernel) please enter the following command in a terminal window:

apport-collect 1117804

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

FTR this was raised as a potential blocker for enabling AppArmor by default on Debian: https://bugs.debian.org/872726. I'm going to investigate why this is a blocker there.

tl;dr: as the audit maintainers said in 2014 (https://www.redhat.com/archives/linux-audit/2014-May/msg00119.html) and 2016 (https://www.redhat.com/archives/linux-audit/2016-April/msg00129.html), we should use events ids from the range that has been allocated to us (1500-1599) instead of from the range assigned to SELinux.

Any plans / ETA to fix this? Regardless of how you would prioritize this problem otherwise, the fact it might prevent AppArmor from being enabled by default in Debian could be a reason to handle it ASAP :)

IMHO we have to ask John Johansen about this, he's working on kernel side.

There was an attempt to revive this Dec. 6, 2017

https://lists.ubuntu.com/archives/apparmor/2017-December/011370.html

upstream there is belief in using a generic audit message types. The problem is that apparmor, selinux and smack messages differ, so they aren't so common.

This is going to have to be revisited, whether it means new numbers/ranges being used or refactoring of messages is unclear at this point.

Meta: I've re-read the discussion from December 2017. If there were messages later than this on the thread, I missed them due to suboptimal mailing list archive presentation. Sorry if this leads me to wrong conclusions!

I lack the skills to do the actual work I think should be done. The only way I can help here is by facilitating the conversation, so I'll do that: I'd like to make sure there's no misunderstanding about the various opinions that were expressed, the current state of the discussion, and what the next steps should be (e.g. who's waiting for whom).

My understanding is that [my personal opinion in square brackets]:

0. Upstream acknowledges that there is a problem and that it would be nice to solve it.

1. There's indeed desire upstream for finding a good balance between sharing (via generic infrastructure and possibly message types) and taking into account that each LSM has different needs. [This makes sense to me: there are probably bits worth sharing instead of every LSM doing their own thing 100% in their dark corner. Now, obviously finding a good balance requires discussion between LSMs to identify what can be shared and what is specific to each, which has its costs (and may require different skills than writing kernel code).]

2. There's a consensus about the fact we need _some_ way to tell which LSM has sent the message. Several options have been mentioned, including adding a new lsm= identifier and using different allocated blocks (be it in the 1400 range or elsewhere). [I'm glad that the door remains open for the option we had in mind initially.]

3. The ball is in our court: upstream proposed several options and I don't see them reach actionable conclusions without our input. At this point, it seems that the next step is: AppArmor developers express their needs. For example:

   * Are there existing messages formats supported by the auditd suite that would work for us and we'd be happy to share with other LSMs? If yes, great: if we start using them our users will benefit from it without having to adapt existing tools.
   * What are our needs that we think are specific to AppArmor? (It might be that once we state them, another LSM developer will say "actually, this could be useful for us too", who knows :)
   * Once we have the answers to the above questions, we can start checking many AppArmor-specific identifiers we need today and how many extra spare ones we want allocated. (Without this info, nobody can decide whether we can fit in the 1400 range.)

John, are we on the same page? If not, I'd love to know what we understood differently :)