Automatically handle Whonix's "Anon Connection Wizard"

[legoktm]

• [x] I have searched for duplicates or related issues

Description

When you provision SDW or start it for the first time, you need to manually step through Whonix's Anon Connection Wizard, it would be nice if we could do that automatically for users, with some override for users who need to use a bridge.

How will this impact SecureDrop/SecureDrop Workstation users?

Users no longer need to manually walk through the Whonix connection interface, which reduces the chances of user confusion or even mistakes.

How would this affect the SecureDrop Workstation threat model?

As long as we allow people a way to set bridges, etc., I don't think it should.

User Stories

• As a user, I don't want to manually step through a dialog that I don't need to.
• As a developer I don't want to repeatedly manually step through the same dialog over and over when I reinstall SDW.

Notes

• Per https://www.whonix.org/wiki/Anon_Connection_Wizard#cite_ref-2 there is no official CLI support
• Kind of assuming that if we just set a file in the correct spot (/usr/local/etc/torrc.d/40_tor_control_panel.conf?) it'll work. We can read the code as necessary to figure this out...
• This may be moot if https://github.com/freedomofpress/securedrop-workstation/issues/456 is adopted sooner rather than later.

[rocodes]

I looked into this. The correct thing to do is adjust the (empty, whonix-provided) file /usr/local/etc/torrc.d/50_user.conf so that it contains the line DisableNetwork 0. That bypasses the anon connection wizard and configures a regular Tor connection as if the user had selected the "Connect" button in the wizard.

A few notes:

• If any SDW users are using Tor bridges, this won't work for them and they will need to remove this line. (When they reboot, the anon-connection-wizard will be retriggered, or they can run it manually).
  • If we're confident that most/all of our SDW users are not using Tor bridges to connect, this seems like a reasonable UX improvement + we can document what users who want to use Tor bridges would need to do. We may need more info on this.
• There's (currently) no harm in entirely replacing the file /usr/local/etc/torrc.d/50_user.conf, since whonix leaves the file alone if it's already present rather than clobbering it on upgrade. The same is not guaranteed to be true about 40_tor_panel_control.conf.
  • But it seems like the proper debian way to do this might be to dpkg-divert that file and symlink to our own file rather than just overwriting it (and I think you can't just overwrite one file in /usr/local anyway or debhelper complains - ask me how I know ;) )
  • Or edit/append to the file in Salt or in the securedrop-whonix-config postinst, but I really like that we are getting away from editing files in place.

[legoktm]

Ooh!

If we're confident that most/all of our SDW users are not using Tor bridges to connect, this seems like a reasonable UX improvement + we can document what users who want to use Tor bridges would need to do. We may need more info on this.

Agreed on getting more info from users first, assuming it matches our intuition I think we could default to no bridges, with some way to flag (maybe "bridges": true in config.json) that manual configuration is desired.

But it seems like the proper debian way to do this might be to dpkg-divert that file and symlink to our own file rather than just overwriting it (and I think you can't just overwrite one file in /usr/local anyway or debhelper complains - ask me how I know ;) )

Heh :) Or maybe a systemd unit to create the file, to make it easy to connect w/ qubesdb/qubes services.

[rocodes]

Or maybe a systemd unit to create the file, to make it easy to connect w/ qubesdb/qubes services.

So the file is already created by whonix, which is why I was looking at dpkg-divert since we'd be replacing a file that we didn't put in place. But I actually think (even though it's what I didn't want to do before) the simplest thing may be to append to the file, maybe in sd whonix config postinst. And I like your idea about making it configurable.