Now there is much more threat when you can’t use USB auth tokens then when you connect an USB flash.
Really I didn’t use USB flash for years already. Even when I need to print something on local print shop I will send it over messenger app. I don’t know who use it already. Everybody send files online.
I the same time I use my FIDO token a lot! I have it connected to all services which support it. I keep there my GPG. I use it for Git signing and auth. I used it even for Ubuntu log in.
Now I installed qubes and I spent hours trying to connect USB to my work qube. And it’s ridiculously complex.
The era of USB worms is gone! Now is era of the USB crypto tokens!
We have to simplify it
On your dom0 terminal, check out available USB devices, using qvm-block command. Note down the device’s name; mainly it is something like “sys-usb:sda”.
Then, get Qubes attach your USB device to your desired qube: qvm-block attach <qube-name-here> <usb-device-name>
Done.
I really like how QubesOS deals with USB devices. I feel in total control knowing that I can plug any device I find lying around, or that I find on the street, to my computer, running sys-usb in disposable-mode, and then fire up a disposable qube, and plug that dirty usb in to my machine, attach it to that ephemeral disposable qube that I just created, check the contents of the usb, and then de-attach it, and destroy the disposable qube that I used to inspect the contents of the usb.
Perfect.
No more weird pauses whenever somebody or some friend hands me over a usb-stick and says, “here bro it is in there, check it out.”
You make it sounds like every USB device can just be attached to a VM, and works out-of-the-box.
Most of my USB devices don’t work with sys-usb, and my yubikey also doesn’t work with the u2f-proxy. Some of the issues might be on me, but saying you just need to attach it to the vm is a gross oversimplification
The OP is not talking about block devices but other USB devices. In the OP’s case it’s a FIDO key, but it could just as well be a webcam or an ICE debugger or a USB microphone. The point is that with few exceptions these non-block devices do seldom work as expected when used via usbip/qrexec.
That’s why it’s great to have more than one USB controller. I have 3 build-in ones in my T430 and added a forth via express card. This allows to assign a specific USB controller to a ‘development’ qube or the like. Either permanently or for a specific use case.
Perfect solution? Far from it. Obviously now the qube is exposed to whatever attack is possible on that port/controller. So proceed with caution.
I’m curious as to which template your sys-usb qubes are built upon.
FWIW, I’ve not had any of the troubles mentioned with sys-usb based on both debian-11-minimal or debian-12-minimal. sys-usb eats up everything as expected. Whether it be block devices, onboard microphone/webcam/bluetooth (when not BIOS disabled), external WiFi/Bluetooth dongles, RF mouse, USB<->RS232 Console cable, Yubikey, Hardware Wallets, MIDI devices, Quad External ML accelerators, cloned/knockoff logic analyzers, USB gadgets (Arduino/RPI/GoodFET/too many to list), etc. “just work”.
Depending upon the scenario, udev rules in the guest may be required for the task at hand.
I have 3 different SDRs, none of them work with sys-usb, and I had the same issues with my FPGA.
They all seem to have the same/similar issues, they need to reset and when that happens they get disconnected from sys-usb, and adding them as persistent doesn’t change anything.
Okay, not so unusual. When you say “adding them as persistent”, do you mean via the “Devices” tab of a qubes in Qubes Manager or the cli equivalent in dom0? Sounds like the one thing you’re missing are additional udev rules in the guest to support this forced “hot-plugging”.
In your case, the udev rules would be applied in your guest qubes, not sys-usb. If you let us know the devices in question, maybe we can come up with some udev rules for you to try in a DispVM before you implement them in the appropriate TemplateVM. Or, do some web searches regarding “usb” “hot-plugging” “udev rules” “<YOUR_AWESOME_DEVICES_HERE>”.
The device gets detached, you can’t do anything with the device unless you use sys-usb to reattach it to the appVM.
I don’t understand how any udev rule is going to impact a device that isn’t connected to the appVM, the device just doesn’t stop working it gets removed from the appVM.
Which is it? Is it “permanently connected” or not? You’ve previously stated that this is how you have configured the devices.
A) your device is connected to your AppVM & your application using said device is “working”
B) your application performs an event with the device which causes a reset which, results in a disconnect
C) upon reset your device is not automagically connected after it is effectively “Hot-plugged”
D) you’ve got to instruct your AppVM how to handle this new event/device.
SDRs are notorious for requiring consistent & balanced voltage to do their thing which, something as simple as using an out of spec USB cable, sour battery, etc. may very well impede. It would not be surprising that the SDRs in question do not have their requirements met by sys-usb.
It was a hell week.
I locked myself 3 times! I don’t understand why QubesOS doesn’t provide virtual keyboard?
Suddenly only touchpad works.
Now it’s pretty clear how to set up FIDO and generally USB.
I don’t know
I meant that real threats are not anymore related to USB flashes anymore.
My Yubikey works with u2f-proxy, and most of other usb devices I tried works quite good with qubes. Seting up u2f proxy is quite simple task, and almost any other usb device should work in plug and play fashion. So the problem is not the design but rather buggy behavior of many things connected to sys-usb. I encountered some problems with setting up u2f-proxy (there is said in the guide that if I use sys-usb VM named sys-usb I shouldn’t mark it as u2f server since it is default, but it looks like it not work if I don’t do that), u2f-proxy is also very slow compering to native u2f services. I also have some strange problems with storage devices under fedora based VMs (and Ubuntu HVMs) while on debian based VMs everything work just fine. I have regular problems with internal wbcam on my skypeVM, there is some strange bug that under WindowsVM my external hardware encrypted usb drive is disconnected after passing through instead performing as drive and virtual cd-rom with decryption app (I found workaround but it is not convenient). Modern Android devices just not work with qubes through USB in most cases…
Most of that issues are reported on github.