Hi, when I encountered a problem with connecting my adb-enabled phone to a VM through sys-usb, I read that I could attach the USB controller directly to the VM that would talk to the phone, which worked with the no-strict-reset=true option. My understanding of the security issue with that option is that the qube with the attached devices shouldn’t be shutdown without shutting down the whole system (is this correct?), so I disabled sys-usb’s autostart and rebooted.
I was then able to use my VM to handle my phone, but I discovered that my SD card controller (and the card in it) was connected to dom0! This didn’t happen with the USB controllers, and as described here USB qubes | Qubes OS it was configured during install with the rd.qubes.hide_all_usb option set in /etc/default/grub. Is there some way to similarly disable the SD controller from dom0?
Lastly, since it’s just a block device that I didn’t mount, is it worth nuking my system and reinstalling qubes?
that is expected behavior. However you may want to assign it to some other VM (sys-usb is a obvious candidate, but you can create some sys-SD or something like that.
Well, probably not. But that depends on your threat model. Or maybe, delete sys-usb and recreate it (see the documentation about sys-usb). If you find it useful you can create disposable sys-usb!
If you do this you cancel attacks inside VM. The problem that remains and is very difficult to tackle is firmware attacks - if some magic happens to tamper your USB controller (or SD card reader controller) firmware, qubes can not protect you much.
In any case, I guess SD card and controller it is way less problematic than any USB device, including a telephone.
Ah, I should have said, sys-usb as automatically configured at install already has the SD controller assigned to it. When it’s running, it gets the SD controller, but when it isn’t automatically switched on at boot, the SD controller defaults to dom0.
I guess what I meant with “should I reinstall” is a much better formulated question: what threats are theoretically plausible if dom0 is exposed to the SD controller with a card inside that doesn’t get mounted, given that I trust the SD controller itself and do not trust the SD card?
If the card is automatically mounted, it’s filesystem is read, then a lot of complex tasks are performed by dom0 AFAIK. At this point, it might be possible to break the security if sophisticated enough bugs in the implementation exist.
On my Lenovos you can disable the SD controller in the BIOS.
You can also hide it from dom0 at boot, as you do with the USB
controllers. lspci will show you the device identifier.
Then add rd.qubes.hide with that identifier to the grub command line,
and the controller will only be available in sys-usb.
I saw this issue too. Scared the shit out of me the first time I popped in an SD card and it said “connected to dom 0”. I will do a sys-SD. But I also have storage on the pci-e bus, I’d like to do a sys-PCIE as well, I don’t have anything else connected to the pci-e ports, no wifi, no 4g etc, but was curious would you know if I do this will it crash or make my system unusable because the PCI-E bus is being used for something I cannot see, like laptop screen perhaps? How could I figure this out? Thank you.
But what’s the actual syntax? For example, is the device ID in the format of 12:34.5? If so, would it be rd.qubes.hide_12:34.5? (I’m completely guessing that an underscore is the right separator here.)
A big problem is that there’s no way to test this without attaching untrusted stuff to dom0.
Aha, perfect, I got this to work! When sys-usb is off, an SD card that I put in doesn’t show up in dom0, and it works like normal when sys-usb is on. Thanks!
I searched around for rd.qubes.hide and can’t find much documentation about it, but I found an example where rd.qubes.hide_pci was used. The relevant line in my /etc/default/grub is GRUB_CMDLINE_LINUX="$GRUB_CMDLINE_LINUX rd.qubes_hide_all_usb rd.qubes.hide_pci=12:34.5"
I’m kind of kicking myself for not having gotten around to making backups of all my VMs before encountering this issue. Knowing that you’re going to possibly expose something to dom0, you could just back up first and restore after.
