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
