configure OSSEC server gnupg directory permissions in securedrop-osse…

[rocodes]

Configure OSSEC server gnupg directory permissions in securedrop-ossec-server post-installation script. Remove permissions configuration from configure_server task.

Status

Ready for Review

Description of Changes

Fixes #5265.

Changes proposed in this pull request:
Remove OSSEC directory permission configuration steps from configure_server task and set them in securedrop-ossec-server post-installation script.
Modify OSSEC /var/ossec/.gnupg directory permission, and sub-directories if existing (required for private-keys.d if ever created) to 700, and files in /var/ossec/.gnupg/* to 600.

Testing

Staging

Check out this branch and make build-debs.

Clean install prereqs

• make staging

Upgrade scenario prereqs

• make upgrade-start
• observe 700 permissions on /var/ossec/.gnupg and 550 permissions on /var/ossec/.gnupg/*
• make upgrade-test-local

On both:

• observe 700 permissions on /var/ossec/.gnupg
• observe 600 permissions on var/ossec/.gnupg/*
• observe no unusual OSSEC errors in /var/ossec/logs/alerts/alerts.log
• Trigger a 'test' journalist alert from the journalist interface, then return to OSSEC logs (above) and observe OSSEC alert for a level 7 "Apache application error" with details "[...] This is a test OSSEC alert" , or observe test alert
• Additional unusual OSSEC errors not present in /var/ossec/logs/alerts/alerts.log
• No references to gpg: Permission denied, trustdb not writable, or Executing "/var/ossec/send_encrypted_alarm.sh,ossec" in /var/log/procmail.log

Prod/Release testing

• Include a check of the permissions on /var/ossec/.gnupg in the cron-apt upgrade scenario for QA

Deployment

1. No special considerations for existing installs--permissions will be upgraded as securedrop-ossec-server package is upgraded
2. No special considerations for new instances.

Checklist

If you made changes to the system configuration:

• Configuration tests pass (Tests have passed on CircleCI. Testinfra tests don't pass on Qubes staging.)

[eloquence]

Visually this looks sound to me. In your testing, does using the 700 and 600 permissions resolve the procmail error? Note that the error is logged to /var/log/procmail.log, so your current test plan would not cover it, I think.

[rocodes]

The reason I suggested looking in /var/ossec/logs/alerts/alerts.log to confirm that the test ossec alert was "sent" is because I assumed people would be testing this on staging (because it makes changes to the securedrop-ossec-server package), where those emails don't actually get sent afaict.

However, I'm poking at this now to update my test plan!

[eloquence]

Hi @rocodes, sorry if the original issue trail is a bit confusing, as I mentioned on #5265 (comment) the alerts did send successfully to me after the reboot cycle, but I see the procmail error logged even though the alert is sent successfully.

[rocodes]

Not sure about the CI failure here. I did rebase on latest develop.

[rocodes]

Hi @rocodes, sorry if the original issue trail is a bit confusing, as I mentioned on #5265 (comment) the alerts did send successfully to me after the reboot cycle, but I see the procmail error logged even though the alert is sent successfully.

Hi, yup that was clear to me-- the test path involves checking to make sure the alert is sent, and then checking to make sure there are no errors in /var/log/procmail.log. Just took me a bit to update the description--hope it works for you.

[eloquence]

For simplicity, I've tested this by running the two find commands on my long-running prod server, to see if this resolves the procmail permission issue (which, as a reminder, was non-breaking, i.e. it did not break email delivery):

$ find /var/ossec/.gnupg -type f -exec chmod 600 {} \;
$ find /var/ossec/.gnupg -type d -exec chmod 700 {} \;

This change broke OSSEC email delivery, with more severe permission errors. The reason is that on my long-running prod instance, the files in /var/ossec/.gnupg are owned by root, not ossec. Permisssion 600 (owner-only) therefore completely denies the OSSEC user access to the keyring. If I change it to 660, it works again (now without any permission error), but that of course is more permissive than we want.

Note that in the Ansible code you're removing, there's logic to set the owner to ossec:

- name: Ensure correct permissions on contents of OSSEC GPG homedir.
  file:
    state: file
    path: "/var/ossec/.gnupg/{{ item.item }}"
    mode: "0600"
    owner: ossec
    group: "{{ ossec_group }}"
  with_items: "{{ gpg_keyring_status.results }}"
  when: item.stat.exists
  tags:
    - gpg

At minimum I think we need to preserve this logic by adding chown commands to postinst along with your chmod additions.

I don't know why the files are owned by root for me; I've definitely run the playbook since the permission fix-up logic was added in #3943. I'm re-running the playbook now to see if the playbook is fixing up the file ownership as intended or not.

[eloquence]

Re-running the playbook does appear to have correctly adjusted the ownership of the files in /var/ossec/.gnupg; I don't know why it didn't do so before and how those files ended up being owned by root. However, because random_seed is not enumerated in the playbook, that file is still owned by root for me, and I'm still getting the permission error on it.

I think if we just add chown commands to your chmod logic in postinst, that should cover this case and fully replace the existing logic in the playbook.

[eloquence]

Checked with @rocodes and they have offered to pick this up again during the 10/15-10/28 sprint.

[eloquence]

So far I've tested manually setting the permissions as you do here in postinst, and that permission configuration seems to make gpg happy -- I no longer see the trustdb errors (and test alerts still send successfully). 🎉 Now attempting to build a staging env as well.

[eloquence]

Staging scenario:

• observe 700 permissions on /var/ossec/.gnupg
• observe 600 permissions on var/ossec/.gnupg/*
• observe no unusual OSSEC errors in /var/ossec/logs/alerts/alerts.log
• Trigger a 'test' journalist alert from the journalist interface, then return to OSSEC logs (above) and observe OSSEC alert for a level 7 "Apache application error" with details "[...] This is a test OSSEC alert" , or observe test alert
• Additional unusual OSSEC errors not present in /var/ossec/logs/alerts/alerts.log
• No references to gpg: Permission denied, trustdb not writable, or Executing "/var/ossec/send_encrypted_alarm.sh,ossec" in /var/log/procmail.log

In fact, procmail.log is zero bytes. That's expected given that email delivery is not enabled in staging. However, as noted above, with these permissions in my prod setup, I do not see the trustdb error (I do see an entry for send_encrypted_alarm.sh,ossec, which I think is expected).

[rocodes]

(I do see an entry for send_encrypted_alarm.sh,ossec, which I think is expected).

One entry is fine since you triggered a test alert, but you shouldn't see an additional one (which would have previously been triggered by the trustdb thing). Sorry this was unclear.

[eloquence]

• make upgrade-start
• ❌ observe 700 permissions on /var/ossec/.gnupg and 550 permissions on /var/ossec/.gnupg/*

I'm observing 700 permissions on the directory, and 600 permissions on its contents.

• make upgrade-test-local

• observe 700 permissions on /var/ossec/.gnupg

• observe 600 permissions on var/ossec/.gnupg/*

• observe no unusual OSSEC errors in /var/ossec/logs/alerts/alerts.log

• Trigger a 'test' journalist alert from the journalist interface, then return to OSSEC logs (above) and observe OSSEC alert for a level 7 "Apache application error" with details "[...] This is a test OSSEC alert" , or observe test alert

• Additional unusual OSSEC errors not present in /var/ossec/logs/alerts/alerts.log

• No references to gpg: Permission denied, trustdb not writable, or Executing "/var/ossec/send_encrypted_alarm.sh,ossec" in /var/log/procmail.log (file is zero bytes, as above)

[eloquence]

tl;dr of my findings above:

1. In prod, using these permissions seems to resolve the original access issue.
2. In staging incl. upgrade scenario, I'm not able to reproduce the original issue, but the permissions are what we expect them to be after the package is upgraded.

[zenmonkeykstop]

The perms issue wasn't reproducible for me on current staging or prod, but tested in the upgrade scenario by changing keyring file permissions manually after make upgrade-start. They were successfully changed to the correct values by the postint.

Once @eloquence's formatting nit is addressed, this is good to go IMO.

[zenmonkeykstop]

Took another spin through the upgrade scenario with the most recent changes. File perms are set to expected values after upgrade and diff looks good.