Dovecot and Apparmor complains at operation file_inherit

[Matyáš Koc]

[Impact]

Users report that while running dovecot there are some issues reported
by AppArmor, specifically regarding "file_inherit" operations:

Jul 12 13:31:19 myserver kernel: [ 3905.672577] audit: type=1400 audit(1499859079.016:363): apparmor="ALLOWED" operation="file_inherit" profile="/usr/lib/dovecot/anvil" pid=3766 comm="anvil" family="unix" sock_type="stream" protocol=0 requested_mask="send receive" denied_mask="send receive" addr=none peer_addr=none peer="/usr/sbin/dovecot"

Jul 12 13:31:19 myserver kernel: [ 3905.672578] audit: type=1400 audit(1499859079.016:364): apparmor="ALLOWED" operation="file_inherit" profile="/usr/sbin/dovecot" pid=3766 comm="anvil" family="unix" sock_type="stream" protocol=0 requested_mask="send receive" denied_mask="send receive" addr=none peer_addr=none peer="/usr/lib/dovecot/anvil"

This is likely caused by an anonymous socket communication channel
between dovecot and anvil.

A fix in the dovecot AppArmor policy was already merged upstream
in commit 1ce8cd21, which is being backported in this SRU.
There was a change upstream that renamed the dovecot profile, so it was
necessary to make a small change on the backport to reference the
correct profile name.

[Test Plan]

Clone the qa-regression-testing repo
https://git.launchpad.net/qa-regression-testing
Setup the machine according to the instructions in the README.multipurpose-vm - specifically the Email section.

Run the dovecot tests from the qa-regression-testing repo:
python3 ./script test-dovecot.py

After running the tests, check dmesg for no DENIED messages:
dmesg | grep DENIED

[Where problems could occur]

This update broadens the dovecot policy, so it won't to cause any
issues regarding a behavior that was previously allowed and it is now
denied.
In addition, the dovecot policy is already in complain mode in
bionic.

[Seth Arnold (seth-arnold)]

I'm surprised about the "addr=none peer_addr=none" -- any idea what's going on here?

Thanks

[John Johansen (jjohansen)]

Its an anonymous socket. The best you can do is

to /usr/sbin/dovecot/anvil add
  unix (send, receive) peer=(label=/usr/sbin/dovecot),

to /usr/sbin/dovecot add
  unix (send, receive) peer=(label=/usr/sbin/dovecot/anvil),

[Matyáš Koc (vilican)]

It is suprising for me too, as I don't know about this problem on 16.04 LTS and I could not reproduce it. It was probably introduced in 17.04 or around that.

I have done some experimenting now and I managed to find out that the problem is caused only by profile for /usr/lib/dovecot/anvil (not dovecot profile itself). Also, adding just "singal," to the profile didn't work.

[John Johansen (jjohansen)]

This is caused by an anonymous socket communication channel between dovecot and anvil. If this problem is not happening in 16.04 (unless you are using the release kernel) then it will be because o a change to dovecot, newer versions of apparmor have been SRUed back to 16.04

[Seth Arnold (seth-arnold)]

Oh, I always forget that unix has _anonymous_ sockets too. Silly complicated things. Thanks John.

[Matyáš Koc (vilican)]

I applied the fix and it looks like it's all working now. I wan't aware of the anonymous sockets, so I was trying wrong things.

Thank you!

[Jamie Strandboge (jdstrand)]

Marking the dovecot task as Invalid since it doesn't ship the profiles.

[Jamie Strandboge (jdstrand)]

@Matyáš, this configuration seems like something you added:

/etc/dovecot/conf.d/10-master.conf
   service auth {
     unix_listener auth-userdb {
       mode = 0666
       user = vmail
       group = mail
     }
     unix_listener /var/spool/postfix/private/auth {
       mode = 0666
       user = postfix
       group = postfix
     }
   }

Is this a standard configuration?

[Launchpad Janitor (janitor)]

[Expired for AppArmor because there has been no activity for 60 days.]

[Launchpad Janitor (janitor)]

[Expired for apparmor (Ubuntu) because there has been no activity for 60 days.]

[Christian Boltz (cboltz)]

For the records: Upstream commit a57f01d86bdb01647966f3eeff7a1cc3fc6abd76 (from 2019-02-10) added rules to allow this (with an additional type=stream restriction, which matches the log mentioned in this bugreport), and was also backported to the maintenance branches.

Therefore I'll mark the AppArmor part as "fix released".

[Christian Ehrhardt  (paelzer)]

This is a post 2.13 fix upstream.
As mentioned by Christian it is in the backport branches, the respective merge for 2.13 is:
$ git tag --contains 28c4dcccc3a339dea8120eb59fea314bc0026b50
v2.13.3
Thereby this is fixed in E&F.

2.12:
$ git tag --contains 1ce8cd213c1f8948658818ac8a9a964755aac6d0
v2.12.3

So this would be open for Bionic (but at low prio since the change can be done as a user:
$ echo "unix (receive, send) type=stream peer=(label=dovecot)," >> /etc/apparmor.d/local/usr.lib.dovecot.anvil
$ echo "unix (receive, send) type=stream peer=(label=/usr/lib/dovecot/anvil)," >> /etc/apparmor.d/local/usr.sbin.dovecot

[Bryce Harrington (bryce)]

Per comment #7 (and re-confirmed with security just now), the fix needed is to apparmor, and just needs a cherrypick to fix.

[Georgia Garcia (georgiag)]

I have attached a debdiff for AppArmor containing the upstream fix.

[Robie Basak (racb)]

What's the user impact here please? Just noisy logs, or are users impacted in a more meaningful way? The downside here is that a rebuild of apparmor is going to result in virtually every Ubuntu Bionic user having to download and install an update. The vast majority of whom aren't using dovecot, or even those that are don't have this profile enforcing, AIUI. And this is for Bionic which was released over four years ago, with only one person reporting themselves as affected in that time. Is this really worth an SRU?

At a minimum, I'd like a proper explanation of user impact please, and then we can reconsider.

[Robie Basak (racb)]

Please also fix the bug status for the Ubuntu development release apparmor package task.

[Robie Basak (racb)]

Bug 1979879 is similar to this, except for samba in Jammy. In both cases, a workaround is trivially available since a user can safely modify the profile directly in /etc.

[Georgia Garcia (georgiag)]

Robie, thank you for taking a look at it.
In this case, the user is impacted by noisy logs, since the dovecot profile is in complain mode. That means that AppArmor does not block actions, it only logs them, so that's probably the reason we are not getting more users reporting this.

I believe you are correct, perhaps an SRU is not worth it here, not because the user can modify the policy, but because dovecot functionality is not being affected.

[Robie Basak (racb)]

OK, rejecting from Bionic then and setting Won't Fix. This can be reconsidered if something new comes up.