[apparmor] AppArmor logging although deactivated

[John Johansen]

On 09/27/2015 07:34 AM, Torsten wrote:
> Hello all,
> 
> I am using OpenSuse 13.2 and wanted to test AppArmor. So I activated it, but it was not doing exactly what I wanted to do yet, so I wanted to deactivate it again. I did this using yast and systemctl and both are telling me, that it is deactivated. aa-status is also telling me the same:
> 
> apparmor module is loaded.
> 0 profiles are loaded.
> 0 profiles are in enforce mode.
> 0 profiles are in complain mode.
> 0 processes have profiles defined.
> 0 processes are in enforce mode.
> 0 processes are in complain mode.
> 0 processes are unconfined but have a profile defined.
> 
> 
> Nevertheless I still get a lot of messages like these in my log:
> [222725.738438] audit: type=1400 audit(1443345412.950:16515): apparmor="ALLOWED" operation="open" profile="/usr/sbin/dovecot" name=2F686F6D652F646F7665636F742F746F727374656E2F6D61696C732F2E44656C65746564204974656D732F646F7665636F742E696E646578 pid=8487 comm="imap" requested_mask="rw" denied_mask="rw" fsuid=1010 ouid=1010
> 
> Only after a reboot these messages are gone.
> 
> Is this expected behavior?
> 
You are encountering a replacement/removal bug that is known, but currently unfixed.

Basically because of how replacement/removal have to be done in the kernel, it is not done atomically, but each task is responsible for removing/updating its own enforcement. There a cases where the task can't actually do this (for any of a various set of reasons), the profile attachment remains, but should be redirected. However there is case that is not being handled correctly, where the task tries to update its cred (the confinement data), fails but instead of following through to the new confinement is falling back to the confinement from the failed attempt to update.

Unfortunately until the kernel is fixed, killing the affected task or rebooting are the only ways to deal with this.