Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.kernel > #58891
| From | intrigeri <intrigeri@debian.org> |
|---|---|
| Newsgroups | linux.debian.bugs.dist, linux.debian.kernel |
| Subject | Bug#872726: linux: apparmor doesn't use proper audit event ids |
| Date | 2017-09-09 19:30 +0200 |
| Message-ID | <unRJT-8V-5@gated-at.bofh.it> (permalink) |
| References | <ugzRL-8iD-7@gated-at.bofh.it> <ulAWS-7Ee-5@gated-at.bofh.it> <ulYPv-5uO-1@gated-at.bofh.it> <ugzRL-8iD-7@gated-at.bofh.it> <ulYPv-5uO-1@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
Cross-posted to 2 groups.
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
Back to linux.debian.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Bug#872726: linux: apparmor doesn't use proper audit event ids Laurent Bigonville <bigon@debian.org> - 2017-08-20 17:00 +0200
Bug#872726: linux: apparmor doesn't use proper audit event ids Vincas Dargis <vindrg@gmail.com> - 2017-08-20 19:10 +0200
Bug#872726: linux: apparmor doesn't use proper audit event ids Vincas Dargis <vindrg@gmail.com> - 2017-08-20 19:10 +0200
Bug#872726: linux: apparmor doesn't use proper audit event ids intrigeri <intrigeri@debian.org> - 2017-09-03 13:10 +0200
Bug#872726: linux: apparmor doesn't use proper audit event ids Laurent Bigonville <bigon@debian.org> - 2017-09-04 14:40 +0200
Bug#872726: linux: apparmor doesn't use proper audit event ids intrigeri <intrigeri@debian.org> - 2017-09-09 19:30 +0200
Bug#872726: linux: apparmor doesn't use proper audit event ids John Johansen <john.johansen@canonical.com> - 2017-09-09 22:20 +0200
csiph-web