Comment # 2 on bug 1132214 from Christian Boltz

Instead of unloading all profiles, better switch them to complain mode:

    aa-complain /etc/apparmor.d/*dovecot*

Complain mode will allow everything, and log what would be denied.
(If the profiles weren't loaded before, restart dovecot.)

Then use dovecot for a while, and attach your /var/log/audit/audit.log.


(In reply to Tim Jones from comment #0)
> Someone needs to sit down and review the bundled Dovecot profiles for
> AppArmor, because at the moment they are distinctly lacking.    And no, I
> don't have the AppArmor expertise necessary.
> 
> So far after many hours I have found I had to add:
> 
> /var/spool/postfix/private/dovecot-auth rwk,
> /var/spool/postfix/private/dovecot-lmtp rwk,
> 
> To:
> 
> /etc/apparmor.d/local/usr.lib.dovecot.auth
> /etc/apparmor.d/local/usr.lib.dovecot.lmtp
> /etc/apparmor.d/local/usr.sbin.dovecot

I'm not sure if you need to add these rules to all 3 profiles. Do you still
have the audit.log events for that? (If not, just remove the lines you added
and run "rcapparmor reload" to reload the profiles - as long as they are in
complain mode, nothing will be blocked.)

> I have tried adding:
> /usr/lib/dovecot/dns-client mrPx,
> /var/run/dovecot/dns-client mrPx,
> To:
> /etc/apparmor.d/local/usr.sbin.dovecot
> 
> But that doesn't work.

"Px" means executing a binary under a separate profile, but there's no profile
for dns-client (yet). Therefore AppArmor will stop the execution of dns-client.
(BTW, the rule for /var/run/dovecot/dns-client looks completely strange -
/var/run/ shouldn't contain executables.)

Basically the same advise as above applies here - put the profiles into
complain mode, ideally remove the rules you added during testing and attach
your audit.log.


As a sidenote: If you are interested, I can also teach you how you can update
the profiles yourself (it's not really hard ;-)