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

[John Johansen]

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,
> 

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

[intrigeri]

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

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

[Laurent Bigonville]

Le 03/09/17 à 13:01, intrigeri a écrit :

Hi Laurent!


Hello,


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.


Kind regards,

Laurent Bigonville

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

[intrigeri]

Hi Laurent!

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?

Thanks in advance!

Cheers,
-- 
intrigeri

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

[Vincas Dargis]

This is upstream bug report:
https://bugs.launchpad.net/ubuntu/+source/audit/+bug/1117804

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

[Vincas Dargis]

On Sun, 20 Aug 2017 16:42:55 +0200 Laurent Bigonville  wrote:

IMVHO, in regard to the recent proposal of enabling apparmor in debian
by default, this needs to be addressed first.


Yes this is very important, although we have aa-logprof to be used as auditing
tool, but I agree that not seeing AppArmor events in your custom auditd report
is rather bad.

We could ask John Johansen if he has it on it's queue. He is upstreaming Ubuntu
patches to mainline Linux, so I guess we depend on his work entirely.

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

[Laurent Bigonville]

Source: linux
Version: 4.12.6-1
Severity: normal

Hi,

Currently the code in the kernel is not using the expected audit event
ids (it's using the one allocated to SELinux, 1400 to 1499) when it's
logging its messages (denials,...).

This has been discussed on the linux-audit back to 2014 and again in
2016, but it seems that nothing has moved. This makes auseach and other
audit tools not list these messages as they are seen as invalids.

Upstream of the audit framework insists that AppArmor should use
events ids from the range that has been allocated to them (1500-1599).
AFAIKS, the apparmor userspace is already supporting messaging from both
ranges (would be nice if this was confirmed).

IMVHO, in regard to the recent proposal of enabling apparmor in debian
by default, this needs to be addressed first.

Regards,

Laurent Bigonville

-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.12.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)