OSSEC test alert does not send, gpg "Permission denied" error in procmail log

[eloquence]

Environment: long-running production instance just updated to 1.3.0 (not manually rebooted yet)

I see OSSEC alerts flowing, but sending a test alert via the Journalist Interface ("Instance Config" section) does not work for me. I see the following error in /var/log/procmail.log on the monitor server:

procmail: Assigning "LASTFOLDER=/var/ossec/send_encrypted_alarm.sh ossec"
procmail: Notified comsat: "ossec@:/var/ossec/send_encrypted_alarm.sh ossec"
From [email protected]  Wed May 13 19:34:21 2020
 Subject: OSSEC Notification - mon - Alert level 7
  Folder: /var/ossec/send_encrypted_alarm.sh ossec                          817
procmail: Executing "/var/ossec/send_encrypted_alarm.sh,ossec"
gpg: gpg: NOTE: trustdb not writable
NOTE: trustdb not writable
gpg: can't create `/var/ossec/.gnupg/random_seed': Permission denied
gpg: NOTE: trustdb not writable

Note: I don't know if this is a recent regression or a longstanding issue with my instance.

[eloquence]

It looks like the issue went away after the nightly reboot. Now I can send test alerts that look as follows:

OSSEC HIDS Notification.
2020 May 14 13:24:09

Received From: (app) 10.20.2.2->/var/log/apache2/journalist-error.log
Rule: 400700 fired (level 7) -> "Apache application error."
Portion of the log(s):

[Thu May 14 13:24:08.370774 2020] [wsgi:error] [pid 3799:tid 117507186415360] [remote 127.0.0.1:53834] ERROR:flask.app:This is a test OSSEC alert



 --END OF NOTIFICATION

Assuming that's the expected format, closing.

[eloquence]

Even though the above email sent (and was encrypted), I still see a gpg "Permission denied" error in the procmail log for the same email. Reopening until we can confirm that it's either a problem with my instance or an expected error that's safe to ignore.

[eloquence]

From the looks of it so far, not high priority, but a good learning issue for @rocodes and myself to poke at in the 5/20-6/3 sprint.

[rocodes]

Can repro, am currently investigating!

[rocodes]

More than anyone probably wanted to know about this

STR: triggered a test alert in the journalist interface, examined mon server (@1.3.0).

lovelace@mon:~$ sudo tail /var/log/procmail.log                                      
[...]
procmail: Assigning "LASTFOLDER=/var/ossec/send_encrypted_alarm.sh ossec"
procmail: Executing "/var/ossec/send_encrypted_alarm.sh,ossec"
procmail: Notified comsat: "ossec@:/var/ossec/send_encrypted_alarm.sh ossec"
From [email protected]  Tue Jun  2 15:22:16 2020
 Subject: OSSEC Notification - (app) 10.20.2.2 - Alert level 7
  Folder: /var/ossec/send_encrypted_alarm.sh ossec                          906
gpg: NOTE: trustdb not writable
gpg: can't create `/var/ossec/.gnupg/random_seed': Permission denied
lovelace@mon: sudo ls -la /var/ossec/.gnupg
total 24
drwx------  2 ossec ossec 4096 May  6 15:28 .
dr-xr-x--- 14 root  ossec 4096 May  6 16:34 ..
-r-xr-x---  1 root  ossec 5046 May  6 15:27 pubring.gpg
-r-xr-x---  1 root  ossec    0 May  6 15:27 pubring.gpg~
-r-xr-x---  1 root  ossec  600 May  6 16:34 random_seed
-r-xr-x---  1 root  ossec    0 May  6 15:27 secring.gpg
-r-xr-x---  1 root  ossec 1200 May  6 15:27 trustdb.gpg

The /var/ossec/.gnupg folder on the mon server has 550 permissions. Writing to the file /var/ossec/.gnupg/random_seed therefore fails.

Whence?

• In the postinst script for the mon server, there's a default chmod -R 550 for the $OSSEC_HOME dir. (The .gnupg directory is then set to 700, but this is not a recursive action):
  

  securedrop/install_files/ossec-server/DEBIAN/postinst

  Line 79 in f6bbe6c

  # Default for all directories

• The configure_server sets perms for the contents of /var/ossec/.gnupg to 600.
  

  securedrop/install_files/ansible-base/roles/ossec/tasks/configure_server.yml

  Line 49 in f6bbe6c

  - name: Ensure correct permissions on contents of OSSEC GPG homedir.

• A difference is expected, but it is noted "only the ossec user should have read/write permissions", when no one ends up with write permissions.
  

  securedrop/molecule/testinfra/staging/mon/test_ossec_server.py

  Line 47 in 1c2a437

  # Permissions don't match between Ansible and OSSEC deb packages postinst.

Is this serious?

From a cursory look, it does not look serious. For example, it is possible to pass a --no-random-seed-file option if using gnupg on a read-only filesystem.

From the gnupg manpage (https://gnupg.org/documentation/manpage.html):
"GnuPG uses a file to store it's internal random pool over invocations. This makes random generation faster; however, sometimes write operations are not desired [...]".

What do?

Either the permissions could be changed to 600 from 550, or if the intention is to use gnupg in read-only mode after the install, we could suppress this warning (eg by looking at --no-random-seed-file and other gnupg options).

[conorsch]

Great write-up, @rocodes!

Either the permissions could be changed to 600 from 550

That sounds like the right approach, largely we're talking about the longstanding #1756 here.

[rocodes]

lightning response, thanks @conorsch. EOD for me but I'll pick this up again tomorrow

[conorsch]

the permissions could be changed to 600 from 550, or if the intention is to use gnupg in read-only mode after the install

Definitely agree we should clean up the permissions. Noting that on the gnupg dir for OSSEC, we actually want 700, not 600—but definitely not 550! I suggest making the change in two places:

• removing the perms-futzing logic for that dir from the playbook, basically excising these tasks

  securedrop/install_files/ansible-base/roles/ossec/tasks/configure_server.yml

  Lines 23 to 59 in f6bbe6c

  	- name: Check if GPG homedir already exists.
  	stat:
  	path: /var/ossec/.gnupg
  	register: gpg_homedir_status
  	tags:
  	- gpg
  	- name: Ensure correct permissions on OSSEC GPG homedir if it exists.
  	file:
  	state: directory
  	path: /var/ossec/.gnupg
  	mode: "0700"
  	owner: ossec
  	group: "{{ ossec_group }}"
  	when: gpg_homedir_status.stat.exists
  	tags:
  	- gpg
  	- name: Check if .gpg files have been created yet in the GPG homedir.
  	stat:
  	path: "/var/ossec/.gnupg/{{ item }}"
  	with_items: "{{ gpg_keyring_files }}"
  	register: gpg_keyring_status
  	tags:
  	- gpg
  	- 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

• updating the postinst for the securedrop-ossec-server package to chmod 700 the gnupg dir, which matches what the postinst for ossec-server is already doing

With that approach, we'll rely on the deb package logic to enforce state on servers during upgrade. In order to test the approach working well, we should use the "upgrade" scenario, to confirm that a server with bad 550 perms gets switched to 700 perms without any use of Ansible.