Workstation Configuration Wizard (simplify key importing)

[deeplow]

The current way to import the Tails SVS' credentials is a bit manual:

• attaching USB
• decrypting USB
• coping the key to dom0
• copy the journalist interface details to dom0
• in dom0 create a config.json with these values

What I am proposing here is a SDW initialization wizard which would be triggered on (first) boot (or when the credentials are not present).

1. Welcome the admin to the SecureDrop Workstation
2. Ask the user to insert the SVS USB (Tails)
3. Ask the user for the decryption key
4. Do the rest in the background
5. Test connection and inform the user in case anything goes wrong

Open Questions

• including in this flow newsrooms who are installing SecureDrop for the first time and starting only on Workstation (no Tails SVS)
• if this shows on the first boot, then we may want to make sure that the Whonix connection wizard does not get in the way. Controlling the ISO and disabling whonix autostart would be away to do this.
• The user should be connected to the internet for the autotesting to work. Should the wizard include some form guidance on connecting to the internet? Or should we leave that to the docs?

[rocodes]

I agree with this idea, I think once our provisioning is set up we should definitely have an easier install flow that asks for less information and automates a significant portion of the installation.

I think there are a lot of parts and decisions here that might need to be considered separately (I have put my initial impressions in parentheses but open to discussion):

• Can we automate a lot more of the install? (Yes)
• Can we do a better job of "validating" the credentials the user provided before install, including network connectivity testing and/or maybe onion service credential testing? (Yes, probably yes, and re the former, there is an existing network check before our updater runs)
• Can we avoid having the user elaborately construct a config.json or construct any config that requires them to use a text editor? (yes)
  • Can we auto-grab the Submission Private Key (and fingerprint) once the SVS is unlocked (yes)
  • Can we auto-grab the workstation credentials from an admin workstation once the drive is unlocked (yes)
• Should we take control of asking the user for their drive passphrase(s)? (No/maybe but I'm not a fan; this is my least favourite part of the export workflow, and I'd say this should be deferred or descoped)
• Should the same VM handle the SVS and the Admin workstation (No; SVS vm should only be attached to vault, admin VM should be attached to a different VM I think)
• Should the wizard, or a wizard, reappear if valid credentials aren't found? (Yes: relevant Pre-flight check: smoke test on VM / RPC configuration before starting #939, leads to below)
• How should the system validate itself at startup and/or watch for or handle config changes (TBD but ongoing/upcoming work is relevant, as are [4.2] Write vm-specific config values to qubesdb #936, Investigate auditd as a tool for monitoring/validating system state #951)

This is what I think so far.

(Edit: also related: #942; See previously-filed #500)

[rocodes]

As for the non-Tails SDW setups, I think that's a good question to keep in mind so we don't box ourselves in with any design choices, but I see it as farther off than a number of our other milestones (blocked on at least #932 , freedomofpress/securedrop-client#2158 but more broadly freedomofpress/securedrop-client#1725, also freedomofpress/securedrop-client#1104, and probably some others of that ilk)

[deeplow]

Thanks for breaking it down into the various phases. That makes it much easier to reason about.

Should we take control of asking the user for their drive passphrase(s)? (No/maybe but I'm not a fan; this is my least favourite part of the export workflow, and I'd say this should be deferred or descoped)

We could put it out of scope. But it may introduce a false idea of security. I see that in the export flow, there's already some integration with asking the user for a LUKS encrypted drive. I was thinking of something similar here.

Also, I may be missing something here. I was thinking that the wizard would run in dom0, not the SVS. Maybe that perhaps alleviates some of your concerns?

In any case, we should talk about this synchronously because I may be missing part of the picture. I need to better understand the security boundaries intended for the SVS and the SDW and when it's OK to cross those. But in general I agree with having a vault VM do the decryption.

[deeplow]

(Edit: also related: #942; See previously-filed #500)

I had not seen #500. This appears to be a duplicate, then. I'll close this issue.