Update AppArmor profile for Xenial

[emkll]

Status

Ready for review

Description of Changes

Fixes #3962 . Opened #4013 as follow up, uncovered in #3962.

Testing

Spin up a staging environment on Xenial:

• make build-debs-xenial
• molecule converge -s libvirt-staging-xenial

Verify there are no further AppArmor violations:

• Perform actions on source and journalist interface (for example, submit documents and reply to those documents, or run the molecule verify scenario)
• Log into the app server and confirm:
• no apparmor="DENIED" in /var/log/syslog or in journalctl -a

Verify that keys are not being monitored by syscheck:

• Log into the mon server, sudo su and run ./agent-control -r -a in /var/ossec/bin to force a syscheck run
• Wait until INFO: Ending syscheck scan appears in /var/ossec/logs/ossec.log`:
• syscheck does not monitor the private keys (hashes are in /var/ossec/queue/syscheck/(app-staging 10.0.1.2->syscheck)

Ensure there is no breakage in Trusty

• make build-debs
• molecule converge -s libvirt-staging
• Ensure the application behaves as expected.

Deployment

These settings will be provided to new and existing installs via deb packages.

Checklist

If you made changes to the system configuration:

• Configuration tests pass

If you made non-trivial code changes:

• I have written a test plan and validated it for this PR

[kushaldas]

Testing

Spin up a staging environment on Xenial:

• make build-debs-xenial
• molecule converge -s libvirt-staging-xenial

Verify there are no further AppArmor violations:

• Perform actions on source and journalist interface (for example, submit documents and reply to those documents, or run the molecule verify scenario)
• Log into the app server and confirm:
• no apparmor="DENIED" in /var/log/syslog or in journalctl -a

Verify that keys are not being monitored by syscheck:

• Log into the mon server, sudo su and run ./agent-control -r -a in /var/ossec/bin to force a syscheck run
• Wait until INFO: Ending syscheck scan appears in /var/ossec/logs/ossec.log`:
• [ x] syscheck does not monitor the private keys (hashes are in /var/ossec/queue/syscheck/(app-staging 10.0.1.2->syscheck)

Ensure there is no breakage in Trusty

• [ ] Spin up staging VMs and ensure the application behaves as expected. -- This is broken.

While trying to submit a message to the source interface.

[Tue Jan 08 09:52:46.536336 2019] [:error] [pid 1482:tid 3633139447552] ERROR:gnupg:Error sending data: Broken pipe
[Tue Jan 08 09:52:46.538154 2019] [:error] [pid 1482:tid 3633443342080] ERROR:flask.app:Exception on /submit [POST]
[Tue Jan 08 09:52:46.538466 2019] [:error] [pid 1482:tid 3633443342080] Traceback (most recent call last):
[Tue Jan 08 09:52:46.538747 2019] [:error] [pid 1482:tid 3633443342080]   File "/usr/local/lib/python2.7/dist-packages/flask/app.py", line 2292, in wsgi_app
[Tue Jan 08 09:52:46.539022 2019] [:error] [pid 1482:tid 3633443342080]     response = self.full_dispatch_request()
[Tue Jan 08 09:52:46.539246 2019] [:error] [pid 1482:tid 3633443342080]   File "/usr/local/lib/python2.7/dist-packages/flask/app.py", line 1815, in full_dispatch_request
[Tue Jan 08 09:52:46.539487 2019] [:error] [pid 1482:tid 3633443342080]     rv = self.handle_user_exception(e)
[Tue Jan 08 09:52:46.539713 2019] [:error] [pid 1482:tid 3633443342080]   File "/usr/local/lib/python2.7/dist-packages/flask/app.py", line 1718, in handle_user_exception
[Tue Jan 08 09:52:46.539954 2019] [:error] [pid 1482:tid 3633443342080]     reraise(exc_type, exc_value, tb)
[Tue Jan 08 09:52:46.540170 2019] [:error] [pid 1482:tid 3633443342080]   File "/usr/local/lib/python2.7/dist-packages/flask/app.py", line 1813, in full_dispatch_request
[Tue Jan 08 09:52:46.540400 2019] [:error] [pid 1482:tid 3633443342080]     rv = self.dispatch_request()
[Tue Jan 08 09:52:46.540660 2019] [:error] [pid 1482:tid 3633443342080]   File "/usr/local/lib/python2.7/dist-packages/flask/app.py", line 1799, in dispatch_request
[Tue Jan 08 09:52:46.540890 2019] [:error] [pid 1482:tid 3633443342080]     return self.view_functions[rule.endpoint](**req.view_args)
[Tue Jan 08 09:52:46.541136 2019] [:error] [pid 1482:tid 3633443342080]   File "/var/www/securedrop/source_app/decorators.py", line 12, in decorated_function
[Tue Jan 08 09:52:46.541380 2019] [:error] [pid 1482:tid 3633443342080]     return f(*args, **kwargs)
[Tue Jan 08 09:52:46.541601 2019] [:error] [pid 1482:tid 3633443342080]   File "/var/www/securedrop/source_app/main.py", line 149, in submit
[Tue Jan 08 09:52:46.541818 2019] [:error] [pid 1482:tid 3633443342080]     msg))
[Tue Jan 08 09:52:46.542008 2019] [:error] [pid 1482:tid 3633443342080]   File "/var/www/securedrop/store.py", line 174, in save_message_submission
[Tue Jan 08 09:52:46.542254 2019] [:error] [pid 1482:tid 3633443342080]     current_app.crypto_util.encrypt(message, self.__gpg_key, msg_loc)
[Tue Jan 08 09:52:46.542535 2019] [:error] [pid 1482:tid 3633443342080]   File "/var/www/securedrop/crypto_util.py", line 233, in encrypt
[Tue Jan 08 09:52:46.542748 2019] [:error] [pid 1482:tid 3633443342080]     raise CryptoException(out.stderr)
[Tue Jan 08 09:52:46.542951 2019] [:error] [pid 1482:tid 3633443342080] CryptoException: gpg: can't open `/var/lib/securedrop/keys/pubring.gpg'
[Tue Jan 08 09:52:46.543197 2019] [:error] [pid 1482:tid 3633443342080] gpg: keydb_search failed: Permission denied
[Tue Jan 08 09:52:46.543412 2019] [:error] [pid 1482:tid 3633443342080] gpg: 65A1B5FF195B56353CC63DFFCC40EF1228271441: skipped: Permission denied
[Tue Jan 08 09:52:46.543637 2019] [:error] [pid 1482:tid 3633443342080] [GNUPG:] INV_RECP 0 65A1B5FF195B56353CC63DFFCC40EF1228271441
[Tue Jan 08 09:52:46.544002 2019] [:error] [pid 1482:tid 3633443342080] gpg: [stdin]: encryption failed: Permission denied

[emkll]

Thanks for the review @kushaldas !

I'm having some trouble reproducing the error you describe locally, could you please provide steps I can use to reproduce the error you've encountered? You state that This is broken: I assume you mean a submission triggers error 500? Are there any AppArmor violations?

I've also updated the test plan with the steps I've used to test the Trusty scenario.

[kushaldas]

You state that This is broken: I assume you mean a submission triggers error 500?

Yes, the step I took and the error message is given below in that comment.

[kushaldas]

I could not reproduce it this time. And after removed the old starging vms, now I can not regenerate the staging env.

    TASK [Create molecule instance(s)] *********************************************
    failed: [localhost] (item={'box': u'fpf/securedrop-app', 'name': u'app-staging', 'provider_override_args': [u"vm.synced_folder './', '/vagrant', disabled: true, type: 'nfs'"], 'box_url': u'../vagrant_packager/box_files/app_metadata.json', 'private_ip': u'10.0.1.2', 'groups': [u'securedrop_application_server', u'securedrop', u'staging'], 'memory': 1024, 'instance_raw_config_args': [u'ssh.insert_key = false']}) => {"changed": false, "item": {"box": "fpf/securedrop-app", "box_url": "../vagrant_packager/box_files/app_metadata.json", "groups": ["securedrop_application_server", "securedrop", "staging"], "instance_raw_config_args": ["ssh.insert_key = false"], "memory": 1024, "name": "app-staging", "private_ip": "10.0.1.2", "provider_override_args": ["vm.synced_folder './', '/vagrant', disabled: true, type: 'nfs'"]}, "msg": "ERROR: See log file '/tmp/molecule/securedrop/upgrade/vagrant-app-staging.err'"}
    failed: [localhost] (item={'box': u'fpf/securedrop-mon', 'name': u'mon-staging', 'provider_override_args': [u"vm.synced_folder './', '/vagrant', disabled: true, type: 'nfs'"], 'box_url': u'../vagrant_packager/box_files/mon_metadata.json', 'private_ip': u'10.0.1.3', 'groups': [u'securedrop_monitor_server', u'securedrop', u'staging'], 'memory': 1024, 'instance_raw_config_args': [u'ssh.insert_key = false']}) => {"changed": false, "item": {"box": "fpf/securedrop-mon", "box_url": "../vagrant_packager/box_files/mon_metadata.json", "groups": ["securedrop_monitor_server", "securedrop", "staging"], "instance_raw_config_args": ["ssh.insert_key = false"], "memory": 1024, "name": "mon-staging", "private_ip": "10.0.1.3", "provider_override_args": ["vm.synced_folder './', '/vagrant', disabled: true, type: 'nfs'"]}, "module_stderr": "", "module_stdout": "--> Validating schema /home/kdas/code/securedrop/molecule/upgrade/molecule.yml.\nValidation completed successfully.\n", "msg": "MODULE FAILURE", "rc": 0}
    failed: [localhost] (item={'box': u'bento/ubuntu-14.04', 'provider_override_args': [u"vm.synced_folder './', '/vagrant', disabled: true, type: 'nfs'"], 'name': u'apt', 'groups': [u'aptservers'], 'memory': 256}) => {"changed": false, "item": {"box": "bento/ubuntu-14.04", "groups": ["aptservers"], "memory": 256, "name": "apt", "provider_override_args": ["vm.synced_folder './', '/vagrant', disabled: true, type: 'nfs'"]}, "msg": "ERROR: See log file '/tmp/molecule/securedrop/upgrade/vagrant-apt.err'"}
    
    PLAY RECAP *********************************************************************
    localhost                  : ok=5    changed=0    unreachable=0    failed=1   

molecule is acting strange on my box

[kushaldas]

@emkll Please go ahead as my vagrant+molecule seems to be in broken state.

[conorsch]

Tested against Xenial, and confirmed no AppArmor denies after submitting and downloading. During the syscheck steps, however, noticed that there is a key dir showing up in syscheck:

root@mon-staging:~# grep -i /var/lib/securedrop/key /var/ossec/queue/syscheck/\(app-staging\)\ 10.0.1.2-\>syscheck 
+++0:33188:33:33:d41d8cd98f00b204e9800998ecf8427e:da39a3ee5e6b4b0d3255bfef95601890afd80709 !1547504544 /var/lib/securedrop/keys/.gpg-v21-migrated

Since I used staging VMs, I didn't have email delivery wired up, but we should probably ignore that dir, as well. Additionally, given that we're at zero AppArmor denies reported in the logs, might be wise to add config tests confirming that in syslog. Don't wait those checks to be flaky, but may help us catch Xenial-related changes sooner rather than later.

Thoughts, @emkll?

[emkll]

Thanks for the review @conorsch, I've addressed your comments:

1. Good catch on the syscheck alert. The file you mention is a flag to indicate that the migration to GnuPG 2.1 was completed (since it's a 1-time migration) [0]. That file would produce at most a 1-time alert (which would have gotten lost in the myriad of other syscheck that might occur during an upgrade). I've nonetheless added the ignore rule in syscheck, so that will be one alert less upon upgrade.

2. I've also added a test to ensure no AppArmor violations are in syslog. I think it's a good idea, but I am not sure how effective it is in it's current form, given the lack of interaction with the application. Happy to amend that test if you have any ideas.

[0] : https://www.gnupg.org/documentation/manuals/gnupg/GPG-Configuration.html

[conorsch]

I am not sure how effective it is in it's current form, given the lack of interaction with the application

Certainly it will be more useful once #3661 lands, but even in the near-term, devs can still do manual browser interaction, then run the verify logic to assert no denials via AppArmor. One foot in front of the other, so to speak.

so that will be one alert less upon upgrade.

Given the cascade of OSSEC alerts the upgrade will generate, perhaps an upgrade target should silence OSSEC (as well as disable Apache and other pre-upgrade steps) ; the install target would then hook everything back up without any changes. Relevant to #3970.