Proposed procedure for using untrusted USB drives

Disposable sys-usb would not prevent attack on USB conroller firmware, and of little help to people with one USB and no PS2 controller (e.g. myself).

I have looked at usbguard. Thank you for the reference. I think udev has similar capabilities. Regardless, implementing security through whitelisting is a lot of work with no guarantee of result. I personally prefer security by isolation approach.

1 Like

Sounds like your saying you tried this. Please confirm: You have tried the procedure you are proposing and checked that the deauthorized USB devices are actually able to get forwarded to other qubes and those other qubes are able to use them (when loading a driver)?

Yes. I’m actively using this procedure all the time. I confirm that on my installation of Qubes (4.0.4) deauthorized USB interfaces (not devices - do not deauthorize devices!) are able to get forwarded to other qubes using standard GUI procedure, that once forwarded, the driver is loaded in those other qubes automatically without any additional user action, and that those other qubes are able to use the USB devices.

I’m still undecided whether there are actual security advantages of this one or whether this is security circus.

For multiple reasons:

  1. IIRC Qubes OS uses usbip over qrexec for USB device attachments. This is a pure software implementation and much different from PCI device attachments which use VT-d. This means that
    a) you are affected by usbip exploits.
    b) not necessarily all devices work with it.
    c) the usbip backend is still handled by sys-usb. Most likely this will include some driver code.
  2. Your instructions need to be executed really early in the VM boot process to avoid race conditions with e.g. USB devices that are plugged in at boot time. That’s why I still consider [usbguard] way superior (there are maintainers who take care of all these details) and way more powerful (your use case is a very simple “block all” [usbguard] policy). Btw it uses the same kernel interface.
  3. For various USB devices (e.g. block devices) it is actually a good idea to keep all driver code in sys-usb to prevent attacks by untrusted USB devices on the destination VM. The aforementioned threat model doesn’t include such much more likely threats though.
  4. The threat model is focused on protecting USB devices attached to sys-usb against each other. If sys-usb is compromised though, it can easily disable all protections of the devices against each other.

In total I believe that if you’re really concerned about one USB device attacking another, use multiple USB VMs and attach each of your USB hubs to dedicated disposable USB VMs and then only use one device per hub/VM per session. There’s full VT-d protection in place then.