Re-think Device Attachment Logic (Qubes 4.3)

[deeplow]

Description

The current system design (as of 1.5.0) auto-attaches printers and USB drives to sd-devices via udev rules. This logic is implemented by giving extra control to sys-usb. Historically, the workstation's approach has been to make the secure action happen by default without user interaction (if that's not needed). In this case, the auto-attachment happens to avoid user mistakes and reduce complexity devices are auto-attached under the hood (to sd-devices).

But our approach has some downsides:

• Brittleness — auto-attachment via udev rules a bit brittle
• Requires messing with files and packages in system qubes (sys-usb, fedora templates) — this nuance has once lead to export functionality being broken for a short period

Qubes 4.3 gives makes device changes and filtering a first-class citizen. And we can (and should) finally move the auto-attach logic out of sys-usb and into dom0 (or a management qube in the future?). This is something that had been considered in the past, actually:

The Qubes core admin API makes it possible to write an extension loaded by qubesd that can react to events like VM startup and shutdown, and changes to the list of devices in the sys-usb VM, so in theory we could watch for those events, run a script in sys-usb to enumerate viable export devices, and automatically attach them to sd-export-usb.

Originally posted by @rmol in #18

How will this impact SecureDrop/SecureDrop Workstation users?

Qubes 4.3 makes device-attachment and deny rules a first-class citizen.

freedomofpress/securedrop-export#18 (comment)

How would this affect the SecureDrop Workstation threat model?

• Current implementation:
  • sys-usb can connect arbitrary devices to sd-devices
  • A malicious device is auto-attached to sd-devices

Threat model implications depend on the particular implementation approach.

User Stories

---

Implementation Proposals

Confirm-once, then auto-attach

First time the device is attached, if it's either a printer

Other possibilities:

• Never ask again — an extra button by which we can deny this device. This is useful if a user has some devices attached that is not supposed to be attached to particular qubes. But some cheap USB devices have the same identifier. (If we needed to store this, we could use sd-devices's qubes-features, which would make this list be backed up)

Threat model implications:

• Adds some user-acknowledgement of new devices being plugged in
• A malicious device can pretend to be one already trusted
• A compromized sys-usb cannot arbitrarily attach devices to sd-devices (once we remove the qubes.USBAttach policy), but it can abuse a pre-established attachment to compromize sd-devices. So it doesn't meaningfully change this risk.

Give sd-app control over device attachment

Wouldn't it be useful if sd-app was aware of the devices in sys-usb? We'll want to consider if this fits our threat model, but if sd-app had the admin.vm.device.usb.Available Admin API permission, it could know the devices listed and choose when they are useful and to which qube they get attached (we can limit where it actually gets attached to).

What would open up UX possibilities:

• knowing immediately if a printer is available (done by the device identity) rather than relying on sd-devices to do the pre-flight check.
• Possibility of starting dedicated back-end qubes to have a specific device attached — if such a thing has threat model advantages. Examples: (1) a disposable just for the printer the user wants to use, which gets destroyed when the user no longer needs to print for a while.
• If multiple USB-devices are plugged in, expose the various devices for the user to choose (kind of like the devices widget in dom0, but limited to the workstation's scope)

This would, of course, be at the cost of exposing sd-app to untrusted device names (but not the actual devices) and giving extra control to sd-app. In our current model, a compromized sd-app is already very serious situation. The other consideration is for use-cases in the future, if we'd want for there to be other uses in the workstation beyond SecureDrop -- which is not a "now" consideration.

Simply Auto-attach

Simply move udev logic out of sys-usb and into dom0 (using the Devices API). This would be qubes extension that listens to newly listed devices and if these match the desired interfaces (i.e. it's a printer or USB device), auto-attach it to sd-devices. This is not possible to do out of the box in Qubes 4.3: see QubesOS/qubes-issues#10368.

Per port

TBD. [We'd need some sort of port-binding prompt]

[deeplow]

I'll leave this as a proposal for further discussion. We don't have to strictly have to have any of these implemented by the time we move to 4.3. We can continue to lean in our udev rules for the moment.