dovecot imap-login profile missing inet6 access

User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20100101 Firefox/11.0

I had some trouble with the AppArmor profiles for Dovecot. After running

    aa-complain /usr/lib/dovecot/imap-login

for a while, aa-logprof failed to create a working profile.

The relevant lines from /var/log/audit/audit.log indicated many instances of the following variety:

type=AVC msg=audit(1333648169.009:11707146): apparmor="ALLOWED" operation="accept" parent=25932 profile="/usr/lib/dovecot/imap-login" pid=5049 comm="imap-login" lport=143 family="inet6" sock_type="stream" protocol=6

After running aa-logconf, the profile did contain the line

    network inet stream,

but what actually was needed was

    network inet6 stream,

After adding this to the profile, everything works.

Reproducible: Always

The "network inet stream" is already in the packaged profile - in other words: it doesn't count ;-)

The problem is caused by a change in the logging format. See the upstream bugreport https://bugs.launchpad.net/apparmor/+bug/800826
(just tested - logprof works if you delete the "lport=143" part)

Independent from that - are there other dovecot-related profiles that need an inet6 rule added? I'd guess usr.lib.dovecot.managesieve-login could need it - at least it already contains an inet rule.

(In reply to comment #1)

> The "network inet stream" is already in the packaged profile - in other words:
> it doesn't count ;-)

Fair enough.

> The problem is caused by a change in the logging format. See the upstream
> bugreport https://bugs.launchpad.net/apparmor/+bug/800826
> (just tested - logprof works if you delete the "lport=143" part)

Ouch! That's over 9 months old already. Any chance of fixing this?

> Independent from that - are there other dovecot-related profiles that need an
> inet6 rule added? I'd guess usr.lib.dovecot.managesieve-login could need it -
> at least it already contains an inet rule.

I don't know, but I guess one would need this if using IPv6 to connect. Updates to sieve scripts on my system oddly enough will use 127.0.0.1, so these will be allowed by the existing rule. However, updating still fails:

Apr 5 23:08:34 mail dovecot: managesieve-login: Login: user=<arjen>, method=PLAIN, rip=127.0.0.1, lip=127.0.0.1, mpid=9319, secured
Apr 5 23:08:34 mail dovecot: managesieve(arjen): Error: sieve-storage: open(/home/arjen/sieve/tmp/ingo-1333660114.M954214P9319.mail.sieve) failed: Permission denied
Apr 5 23:08:35 mail dovecot: managesieve(arjen): Connection closed bytes=7979/489

I can make this work again by running /usr/sbin/dovecot in complain mode, but strangely enough this doesn't log anything in /var/log/audit/audit.log. But this is probably unrelated and will be something in the profile for /usr/sbin/dovecot.

(In reply to comment #2)
> (In reply to comment #1)
> > The problem is caused by a change in the logging format. See the upstream
> > bugreport https://bugs.launchpad.net/apparmor/+bug/800826
>
> Ouch! That's over 9 months old already. Any chance of fixing this?

AFAIK Steve is working on a patch already, so there's hope ;-)

> > Independent from that - are there other dovecot-related profiles that need an
> > inet6 rule added? I'd guess usr.lib.dovecot.managesieve-login could need it -
> > at least it already contains an inet rule.
>
> I don't know, but I guess one would need this if using IPv6 to connect. Updates
> to sieve scripts on my system oddly enough will use 127.0.0.1,

Not ::1 ? ;-)
Seriously: allowing IPv6 isn't a big risk IMHO, so I'll propose it upstream.

> However, updating still fails:

> open(/home/arjen/sieve/tmp/ingo-1333660114.M954214P9319.mail.sieve)
> failed: Permission denied

> I can make this work again by running /usr/sbin/dovecot in complain mode, but
> strangely enough this doesn't log anything in /var/log/audit/audit.log.

Indeed, that sounds really strange.
What happens if you add
    /home/arjen/sieve/tmp/*.mail.sieve rw,
to your dovecot profile and switch it back to enforce mode?

(In reply to comment #3)

> Indeed, that sounds really strange.

I found problem with aa-logprof failing to update the profile. It gets confused if you keep your backup copies in the same directory (which is understandable). After moving them out of the way, it worked as expected. :-)

> What happens if you add
> /home/arjen/sieve/tmp/*.mail.sieve rw,
> to your dovecot profile and switch it back to enforce mode?

That almost worked. :-)

I added

  /home/*/*.sieve rw,
  /home/*/sieve/*.sieve w,
  /home/*/sieve/tmp/*.sieve rw,

and after that, I could update my sieve scripts again. But where sieve scripts are stored is probably going to be pretty site-specific, so I don't think this will be worth adding to the default profile.

(In reply to comment #4)
> I added
>
> /home/*/*.sieve rw,
> /home/*/sieve/*.sieve w,
> /home/*/sieve/tmp/*.sieve rw,
>
> and after that, I could update my sieve scripts again. But where sieve scripts
> are stored is probably going to be pretty site-specific, so I don't think this
> will be worth adding to the default profile.

Indeed, that makes things interesting[tm] ;-)

FYI: the main bug is fixed upstream (bzr r2022).
I also added the patch in home:cboltz (currently building) and will forward it to security:apparmor if it works as expected.

This is an autogenerated message for OBS integration:
This bug (755923) was mentioned in
https://build.opensuse.org/request/show/113963 Factory / apparmor

Fixed in security:apparmor (where you can also find packages for 12.1) and factory.

I'll probably also submit an update for 12.1 when AppArmor 2.7.3 is released (whenever that is - there is no planned release date yet).