Discuss "offline mode" configuration option that deletes files in sd-app on shutdown

[kennethrrosen]

Presently, files downloaded in the client VM persist on reboots. For most use-cases this may be suitable for offline usage, but is not entirely ideal for use-cases where the workstation is mobile and may be running even if SDW is not.

Suggestion: offer admins/users the choice to delete submissions and downloads on VM shutdown, which would force the client VM to redownload when connectivity was reestablished to prevent submissions from persisting on the local disk.

[rocodes]

Hi @kennethrrosen, thank you for filing this :) Basically, this is an issue of if "Offline Mode" should be optional/configurable.

I dug back in history and found this discussion as well: https://github.com/freedomofpress/securedrop-client/issues/742 ; I think it's a configuration option worth supporting, although I'm not sure where it lands on our roadmap at this point since we have a bit of a backlog.

However: we would have to be really clear about what protections we are/ aren't promising when we say "no offline mode." SecureDrop Workstation is primarily designed as a system that will be operated in a secured location. Getting rid of 'Offline mode' capabilities (essentially, deleting data directories such as the ~/.securedrop_client/data diretory on the sd-app vm, or the entire ~/.securedrop_client directory) is not an anti-forensic measure. (Even using an sd-app DispVM would not be an anti-forensic measure, since dispvms don't run exclusively in RAM -- see upstream discussions on volatile image encryption and/or in-memory only dispvms, which to my knowledge are still ongoing).

In addition to sd-app, other SecureDrop Workstation VMs contain sensitive information on disk (key material in the vault VM, tor hidden service authentication credentials in the sd-whonix vm, sensitive info in dom0, and anything you have set up yourself in other vms such as the vault vm). So basically, there are some potential benefits but removing files from sd-app, but a lot of other sensitive system information/components are still exposed while offline.

Hope that makes sense! I'm going to rename this issue (re "offline mode") so that it's more searchable when this discussion comes up.

[rocodes]

Also: noting for the team this would be currently implementable, but would require more thinking regarding the proposed architectural principle of the server as a message queue when it comes to e2ee.

[zenmonkeykstop]

+1 to @rocodes points here - if an adversary gets access to a workstation with an unlocked disk then there are multiple points of compromise to consider. This is one reason we tend to view the system as being a dedicated workstation rather than an application on a general-purpose Qubes install.

It's also why that the setup process changes things like system behaviour on lid close from suspend to power off, to help ensure that an unattended system is shut down rather than being left in a state with FDE unlocked. (To be fair, this is probably a good idea for any Qubes system being used in an insecure environment, along with AEM/BIOS anti-tampering config if possible.)

[kennethrrosen]

Continuing my spitballing here ...

@zenmonkeykstop thanks so much for noting the system behavior changes; I think you're right that these should be opt-out options on any vanilla Qubes system. When AEM (trenchboot) becomes UEFI compatible, this would be most helpful for my usecase.

@rocodes I wonder if a split-SDW RPC ruleset with vault could repopulate that sensitive data from the Vault vm. There seems some benefit and low overhead from deleting sd-app directories and data on shutdown. And reinstating the securedrop instance secrets, credentials, etc., from Vault through split-SDW.