[apparmor] [Bug 1117804] Re: ausearch doesn't show AppArmor denial messages

[intrigeri]

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 :)

-- 
You received this bug notification because you are a member of AppArmor
Developers, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1117804

Title:
  ausearch doesn't show AppArmor denial messages

Status in AppArmor:
  Confirmed
Status in audit package in Ubuntu:
  Confirmed
Status in linux package in Ubuntu:
  Incomplete

Bug description:
  The following command should display all AVC denials:

  ausearch -m avc

  However, it doesn't work with AppArmor denials. Here's a quick test
  case to generate a denial, search for it with ausearch, and see that
  no messages are displayed:

  $ aa-exec -p /usr/sbin/tcpdump cat /proc/self/attr/current
  cat: /proc/self/attr/current: Permission denied
  $ sudo ausearch -m avc -c cat
  <no matches>

  ausearch claims that there are no matches, but there's a matching
  audit message if you look in audit.log:

  type=AVC msg=audit(1360193426.539:64): apparmor="DENIED"
  operation="open" parent=8253 profile="/usr/sbin/tcpdump"
  name="/proc/8485/attr/current" pid=8485 comm="cat" requested_mask="r"
  denied_mask="r" fsuid=1000 ouid=1000

To manage notifications about this bug go to:
https://bugs.launchpad.net/apparmor/+bug/1117804/+subscriptions