[0.7.0] Journalist Notification error when there is a 2nd install run prior to initial reboot

[emkll]

Bug

Upon activating journalist notifications, running ./securedrop-admin install before the first daily reboot time produces a SecureDrop Submissions Error that may confuse administrators. Note that daily journalist notification emails are correctly sent and received (if configuration is correct), and that the error message is potentially misleading.

Description

• Install/upgrade to 0.7
• run ./securedrop-admin install to enable journalist notifications
• run ./securedrop-admin install again to enable ssh over local host

This will trigger a reboot with a absent submissions_today.txt file (it is created once the next cron runs manage.py were-there-submissions-today) which will in turn throw a SecureDrop Submission Error :

/var/ossec/process_submissions_today.sh failed to find 0/1 submissions boolean in the following OSSEC alert

>From [email protected]  Thu May 10 19:53:08 2018
Return-Path: <[email protected]>
X-Original-To: root@localhost
Delivered-To: root@localhost
Received: from notify.ossec.net (localhost [127.0.0.1])
	by ossec.server (Postfix) with SMTP id 1E5BF180452;
	Thu, 10 May 2018 19:53:08 -0400 (EDT)
To: <root@localhost>
From: OSSEC HIDS <[email protected]>
To: <root@localhost>
Date: Thu, 10 May 2018 19:53:08 -0400
Subject: OSSEC Notification - mon - Alert level 7
Message-Id: <[email protected]>


OSSEC HIDS Notification.
2018 May 10 19:53:03

Received From: mon->syscheck
Rule: 550 fired (level 7) -> "Integrity checksum changed."
Portion of the log(s):

Integrity checksum changed for: '/var/ossec/.procmailrc'
Size changed from '162' to '261'
What changed:
6,8c6,13
< :0 c
< *^To:.*root.*
< |/var/ossec/send_encrypted_alarm.sh
---
>
> :0 B
> * /var/lib/securedrop/submissions_today.txt
> |/var/ossec/process_submissions_today.sh
>
> :0 E
> * ^To:.*root.*
> |/var/ossec/send_encrypted_alarm.sh ossec
Old md5sum was: '<oldmd5>'
New md5sum is : '<newmd5>'
Old sha1sum was: '<oldsha1>'
New sha1sum is : '<newsha1>'



 --END OF NOTIFICATION

Expected Behavior

SecureDrop Submissions Error email should not be sent, as the instance is properly configured.

Actual Behavior

SecureDrop Submissions Error is sent.

Comments

Given how unlikely this is to occur in real-world scenarios and complex this would be to fix at this stage, perhaps a small docs change (or no change at all) for 0.7.0. I can see this happening more frequently for new installs than for existing installs.

[emkll]

I would be interested to see if anyone can reproduce this, as it's a fairly specific edge case.

To fix this issue, there are 2 solutions we can implement at install time if /var/www/securedrop/submissions_today.txt is not present:

1. Drop /var/www/securedrop/submissions_today.txt with 0, which will yield an potentially incorrect journalist notification email if the instance reboots before the scheduled time.
2. Run /var/www/securedrop/manage.py were-there-submissions-today, which will populate /var/www/securedrop/submissions_today.txt with a more accurate (but also potentially incorrect - if there was a submission between install time and reboot time) journalist notification.

The second option should not leak more information, as journalist emails are throttled to at most once every 24h, and strikes me as more robust/maintainable and less inaccurate for end-users.

[redshiftzero]

So to test this I:

1. Deleted /var/lib/securedrop/submissions_today.txt on a prod VM with journalist notifications enabled
2. Rebooted the app VM

Based on the information here, I would expect to see a "SecureDrop Submissions Error", but I didn't get one. Confirm this was on 0.7.0-rc4? Since I expect that this behavior would change significantly between 0.7.0-rc3 and 0.7.0-rc4 due to the merge of #3384

[emkll]

Thanks for testing, @redshiftzero . I've tried reproducing again on a day old instance using the method you described (which should trigger the bug described) and could not reproduce. Closing this ticket.