[xenial] Update AppArmor rules to work on Trusty, Xenial

[eloquence]

Explicit rules are required for Apache mpm worker/event changes. gpg2 policy should permit links via /var/lib/securedrop/keys/* l or similar.

For simplicity, we should update AppArmor rules to work for both Trusty and Xenial, using a single template file for both distros.

Part of #3204.

[conorsch]

Took a look at the WIP branch in 3962-apparmor-xenial. As @emkll reported in standup today, journalist replies are not properly decrypted. Documenting additional unhandled gpg-related AppArmor failures for follow-up:

root@app-staging:~# journalctl -a | grep 'apparmor="DENIED"'
Dec 17 20:45:42 app-staging audit[1770]: AVC apparmor="DENIED" operation="mkdir" profile="/usr/sbin/apache2" name="/var/lib/securedrop/keys/openpgp-revocs.d/" pid=1770 comm="gpg2" requested_mask="c" denied_mask="c" fsuid=33 ouid=33
Dec 17 20:45:42 app-staging kernel: audit: type=1400 audit(1545079542.972:22): apparmor="DENIED" operation="mkdir" profile="/usr/sbin/apache2" name="/var/lib/securedrop/keys/openpgp-revocs.d/" pid=1770 comm="gpg2" requested_mask="c" denied_mask="c" fsuid=33 ouid=33
Dec 17 21:41:18 app-staging audit[3699]: AVC apparmor="DENIED" operation="mkdir" profile="/usr/sbin/apache2" name="/var/lib/securedrop/keys/openpgp-revocs.d/" pid=3699 comm="gpg2" requested_mask="c" denied_mask="c" fsuid=33 ouid=33
Dec 17 21:41:18 app-staging kernel: audit: type=1400 audit(1545082878.313:23): apparmor="DENIED" operation="mkdir" profile="/usr/sbin/apache2" name="/var/lib/securedrop/keys/openpgp-revocs.d/" pid=3699 comm="gpg2" requested_mask="c" denied_mask="c" fsuid=33 ouid=33
Dec 17 21:42:06 app-staging audit[3744]: AVC apparmor="DENIED" operation="exec" profile="/usr/sbin/apache2" name="/usr/bin/pinentry-curses" pid=3744 comm="gpg-agent" requested_mask="x" denied_mask="x" fsuid=33 ouid=0
Dec 17 21:42:06 app-staging kernel: audit: type=1400 audit(1545082926.601:24): apparmor="DENIED" operation="exec" profile="/usr/sbin/apache2" name="/usr/bin/pinentry-curses" pid=3744 comm="gpg-agent" requested_mask="x" denied_mask="x" fsuid=33 ouid=0

Those should indeed be handled in the profile, but they're insufficient to explain the breakage. Switching the apache2 profile in AppArmor to "complain" mode and bouncing the service doesn't resolve, for example. One lead is that the redis worker appears to be failing, as evidenced by:

root@app-staging:~# cat /var/log/securedrop_worker/out.log 
Error 99 connecting to localhost:6379. Cannot assign requested address.
Error 99 connecting to localhost:6379. Cannot assign requested address.
Error 99 connecting to localhost:6379. Cannot assign requested address.

More research required.

[conorsch]

After setting all AppArmor profiles to complain, and even flushing the iptables rules, the no-journalist-response issue persisted. As such, it appears not to be directly related to AppArmor policies, so I propose we open another dedicated issue to track, and press forward with the minor fixes to the existing profiles outlined above.

Also worth pointing out we have a few documented AppArmor profile tweaks in https://github.com/freedomofpress/securedrop/compare/test-xenial-upgrade-path , left over from #3491. Let's review those and include if warranted.

[conorsch]

Redis worker issue may be a red herring, given that I'm able to pull up the same error logs even on Trusty, when running staging VMs locally. Let's try moving forward with programmatically updated profiles (e.g. via aa-logprof, see docs) and see how far that gets us.