Bug#872726: linux: apparmor doesn't use proper audit event ids

[intrigeri <intrigeri@debian.org>]

Hi Laurent & everyone else who's listening!

Laurent Bigonville:
> Le 03/09/17 à 13:01, intrigeri a écrit :
>> Laurent Bigonville:
>>> IMVHO, in regard to the recent proposal of enabling apparmor in debian
>>> by default, this needs to be addressed first.
>> I'm genuinely curious why this should be a blocker for Debian: this is
>> not obvious to me as a number of distros could enable AppArmor by
>> default and can apparently live with this bug.
>>
>> Can you please make it explicit, e.g. describing what exact use cases
>> would be harmed by enabling AppArmor by default without fixing this
>> bug first?

> I think that having the denials of a MAC properly logged is important for both people
> developing their policy and also for intrusion/non conformity detection.

> If someone wants to send their logs to some logging services (ELK/splunk/...) having
> the messages properly logged/categorized seems to be the start here.

I see, thanks for the explanation! I agree it's important and I'm sad
this bug makes AppArmor look a bit rough around the edges (because
that doesn't correctly reflect my experience as a user, sysadmin and
distro maintainer).

I'll look closer at each of these use cases from the "what would we
*break* if we enabled AppArmor by default" perspective:

 * people developing their own AppArmor policy: 100% of the existing
   AppArmor policy was developed without proper audit event IDs;
   I'll be happy to give ausearch(8) a try once AppArmor does the
   right thing, but so far I can very well live without it.

   ⇒ from a user-centric perspective, I don't see why this bug would
   be a blocker as far as this use case is concerned.

 * intrusion detection: the current state of things in Debian (no MAC
   framework enabled by default) does not give any such capability to
   system administrators; the proposal of enabling AppArmor by default
   does not pretend it'll magically give this bonus feature.

   ⇒ AppArmor improves other things, just not this one, or at least
   not in an ideal way; too bad, but I don't see why this limitation
   would be a blocker.

 * centralized logging: enabling AppArmor by default will generate
   audit events; if nothing improves on this front, they'll be
   erroneously tagged type=1400 and thus might land into a SELinux
   bucket or similar by mistake, which can be confusing for sysadmins
   who also run SELinux-enabled systems, and even more so once one can
   stack SELinux and AppArmor.

   ⇒ I understand there *is* definitely potential for painful impact
   here. We'll need to keep an eye on this when evaluating "AppArmor
   by default in Buster?" 1 year after it's been enabled by default
   (as per my proposal on -devel@). But I bet this bug would have been
   fixed a while ago if it was a serious problem in practice:
   apparently, tons of Ubuntu and SUSE sysadmins have apparently
   managed to cope with this bug just fine for many years.

So I see very little ground for arguing this bug is a blocker for
enabling AppArmor by default in testing/sid, and reconsidering a year
later — after all, it's one of the purposes of the evaluation
exercises: nobody claims AppArmor is perfect, and what's at stake is
rather whether it brings more value than costs for Debian and its
users. The best, the good, enemies, etc. :)

If I misunderstood something, sorry! I'm all ears.

Cheers,
-- 
intrigeri