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. -- AppArmor mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
