Tighten svs.sqlite file permissions

[eloquence]

As noted in the December 2020 SecureDrop Workstation audit:

During the fixes review we noticed that the SecureDrop Workstation's SQLite database file located in the ~/.securedrop_client``/svs.sqlite path in the sd-app VM, has too broad file permissions (-rw-r--r--) so it is readable by other users. This database contains sensitive data such as messages, replies or submissions file paths (but not their content). The database's parent directory (.securedrop_client) has proper permissions (-rwx------) so it isn't possible to access the database file directly. However, if an attacker found a way to enter that directory or reach the database file through other means, they could read sensitive data such as messages sent by sources or journalists.

Qubes is a single user OS configured with passwordless sudo, but we still generally agree that we want to enforce conservative permissions as was also done in #1226, so this is a finding that we still want to address.

[eloquence]

Note that this also applies to config.json and sync_flag in the ~/.securedrop_client folder on sd-app. As part of resolving this issue, we can consider phasing out use of these files (see #1224 re: config.json).

[sssoleileraaa]

To close out this issue let's ensure all files in the ~/.securdrop_client directory have the proper restricted permissions. Removal of config.json is being tracked in the issue mentioned above (#1224) and we can track removal of sync_flag here: #1255

[sssoleileraaa]

Note: config.json is already being created with the proper permissions: https://github.com/freedomofpress/securedrop-workstation/blob/d6ae7bfff33d207846e3d17a6e50ce7be39b539f/dom0/sd-app-config.sls. The client does not ensure the file has the correct permissions, but since this file is going away and currently is created with the correct permissions, this ticket does not have to be held up on this specifically.