I’m still undecided whether there are actual security advantages of this one or whether this is security circus.
For multiple reasons:
- 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.
- 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.
- 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.
- 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.