Disable executable scripts in AppVMs other than sd-app

[eloquence]

In the current template consolidation plan (freedomofpress/securedrop-workstation#471) we anticipate that the securedrop-client package will end up being installed in AppVMs that don't need it, e.g., sd-proxy. We want to ensure that the client is not accidentally opened in a VM in which it is not meant to be run. While RPC policies will restrict the proper functioning of the client in any VM other than sd-app, we should still prevent it from being run to reduce confusion.

We want to ensure that client-specific configurations and scripts are not installed in those VMs. In addition to MIME types (tracked in freedomofpress/securedrop-builder#188 and freedomofpress/securedrop-workstation#603), that includes the two executable scripts in the files folder:

• securedrop-client
• sd-app-qubes-gpg-domain.sh (sets the QUBES_GPG_DOMAIN environment variable used to configure the Qubes GPG wrapper in the split GPG architecture)

[eloquence]

One option @emkll and I discussed today was to check hostname of the VM, and exit out if these scripts are invoked in a VM other than sd-app.

[sssoleileraaa]

If we enforce app-to-vm execution restrictions, then i want to advocate for a way to easily disable this when running securedrop-workstation in "dev" mode. I used to do development in the sd-managed vms, but now I use a much more developer-friendly system of developing client and sdk in a dev vm (not sd-app) and the proxy in a dev vm (not sd-proxy). This also allows us to generate sdk cassettes for api calls over qrexec, see https://github.com/freedomofpress/securedrop-sdk/blob/30a28463270ffc44bfaeb89776e5a4addc9c3e8a/README.md#generating-cassettes-for-api-calls-over-qrexec.

[eloquence]

That makes sense -- perhaps we could override the name of the VM via env var, or disable those checks in a dev environment altogether.