search

freedomofpress / securedrop-updater

Update policy enforcement for the SecureDrop Workstation
GNU Affero General Public License v3.0
0 stars 0 forks source link

Updater does not support ethernet via USB device #39

Open rocodes opened 2 years ago

rocodes commented 2 years ago

Some organizations using SecureDrop workstation use a wired connection. Many laptops no longer offer an ethernet port. However, using a USB-ethernet dongle means that the device will autoattach to sys-usb, not sys-net, disrupting updater runs and causing them to fail when sys-usb is rebooted.

The current solution is to manually intervene during the updater run and re-attach the USB device when sys-net or sys-usb reboot.

This is a discussion issue to track if/how we want to better support this use-case.

eloquence commented 2 years ago

As we think about the SecureDrop Workstation longer term, I think it's worth revisiting the auto-attach logic in general, because it changes core Qubes behavior to provide a usability benefit specific to the SecureDrop Workstation.

Are there alternative ways that sd-devices could obtain USB access when needed, instead of attaching every plugged in USB device to sd-devices? If sd-devices could request access to USB devices from the user (by way of a dom0 permissions dialog) when an export is initialized, that could maybe let us avoid manual interaction with the device manager, while also avoiding over-eager auto-attachment.

eaon commented 2 years ago

I agree the auto-attach logic is worth revisiting, however it's somewhat distinct from the issue that @rocodes raises here - at least unless you meant to imply a solution could be to extend our auto-attach functionality to make USB dongles auto-attach to sys-net.

The updating and installing logic assumes there will always be a network connection available once the process has started - which, as we've experienced in several ways by now, isn't always the case. Could be faulty firmware, lack of USB-dongle, or a disposable sys-net qube (which I think would be great if we supported btw).

As @rocodes knows, we already do a network check and make decisions based on that: https://github.com/freedomofpress/securedrop-workstation/blob/356b289390005d59eaa0efd2cd7647c4f75e3b9d/launcher/sdw_updater_gui/UpdaterApp.py#L192-L215

We could use this approach again but disperse it throughout the update/install process, after we restart sys-net. I think this would be great to keep in mind for when we revisit exactly how provisioning/updating happens in order to streamline the Python/Shell/Salt+cmd flow.

As for auto-attach for sd-devices, I have ideas that involve admin.vm.device.block.* and admin.vm.device.usb.* RPC calls, but I think that'd be better to elaborate on in another ticket.

eloquence commented 2 years ago

@eaon and I chatted a bit about this today as part of an updater code walkthrough. Based on reading the code, we didn't think that the updater would fail in this scenario. Afterwards I tried to reproduce the original issue, and was unable to do so. Here's what I see happening:

  1. At least with an Apple USB-to-Ethernet adapter, our sd-devices rules don't grab the USB device when it is plugged in. The udev rules are defined here; they should only fire on printer or storage devices, and that's consistent with the behavior I'm observing.
  2. If (and only if) I manually attach the adapter to sys-net, I'm able to connect via Ethernet.
  3. The updater runs to successful completion using the Ethernet connection. As part of that process, sys-usb is restarted without any errors. At that point I lose connectivity. (Note that if a WiFi connection is stored in the network manager, it tries to recover by connecting to it, so for testing purposes, I deleted my stored WiFi connection.)
  4. The SecureDrop Client login screen appears. I have to manually re-attach the adapter to sys-net to recover connectivity before logging in.

It's possible that there are USB-to-Ethernet adapters that cause additional problems. During an update run where there are unrelated errors (e.g. due to Whonix update problems) it would also be easy to infer that both problems (the updater displaying an error, and the network connection being unavailable after the update) have the same root cause.

At minimum, I think we can add some documentation for users to re-attach the device after the update run.

zenmonkeykstop commented 1 year ago

Needs confirmation, and at least said docs update. Moving to updater repo so we don't lose track.