Bug#872726: linux: apparmor doesn't use proper audit event ids
On 09/09/2017 10:25 AM, intrigeri wrote:
> 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.
>
define properly logged, apparmor uses the common LSM audit subsystem
the same as smack, and selinux.
>> 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.
>
It complicates things because while all LSMs using the common LSM audit
frame work share 1400, the userspace end of audit only has fields
for selinux defined for 1400.
That is there is a disconnect between userspace and kernel. Userspace
has argued the kernel should change.
> * 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.
>
It depends on what you mean by erroneously tagged. AppArmor used to have
the audit range 1500-1599. When the LSM audit infrastructure was created
all LSMs using itwere moved to have id 1400. This was a deliberate choice
made by the kernel community, alls LSMs that use this are affected and
apparmor has had to live with it.
>From an audit tagging perspective 1500 was much better, I would like
to see apparmor move back to 1500 but apparmor will continue to
use the common LSM audit infrastructure, so the change needs to
be agreed to by more than just the apparmor devs.
> ⇒ 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,
>
Reply to: