Can USB devices see/infect one another in sys-usb?

General Discussion
1

I’ve been reading through the Qubes docs and have some questions about USB device security, particularly about how connected USB devices interact with one another. I looked further into the Qubes docs, subreddit, and forums, but they have, for the most part, left me more confused with unfamiliar concepts/terminology (e.g. USB stacks & controllers, bus interconnect, etc.) and didn’t answer my particular question. However, from what I did understand:

  1. dom0 getting infected is not a feasible concern, assuming that no files are ever transferred to dom0, I don’t use a USB keyboard, and that malicious USB devices are never connected to dom0
  2. A malicious USB device could hijack whatever target qube its connected to, regardless of whether or not it’s connected through a USB qube
  3. This can also occur the other way around (a target qube infecting a once trusted USB device) due to malformed partition tables

So then my question is, could a malicious USB device hijack other USB devices connected to the same USB qube? Could such a device also hijack the USB qube itself? (For example, I connect a malicious USB device to my PC, which is automatically connected to the USB qube. A separate USB storage device is also connected to that same USB qube. Could that USB storage device get infected by the malicious USB?)
If these are possible, what mitigations are available? Does the USB qube get “reset” whenever I shut down Qubes or sys-usb?
Also, does any of this apply to the SD card readers in laptops? I don’t know if they’re typically PCI or USB devices.

2

USB devices can’t communicate directly between themselves bypassing USB host so malicious USB device can’t infect other USB devices directly. Only if malicious USB device first infect USB host system then it can access other devices.
But in some cases malicious device can sniff other USB devices communication with host:

If your sys-usb is configured as DisposableVM qube then yes. If it’s configured as standard AppVM then no.

I think they are typically connected to PCI but it could be USB as well, it depends on laptop manufacturer.

3

Malicious USB device can poison USB controller, so bye-bye to all devices attached to it regardless of “disposability”.

4

So even if sys-usb is disposable and I connect different devices during different sessions, they’re still screwed?

5

So who would be the host in the context of Qubes? dom0? sys-usb?

My sys-usb’s template is fedora-38-dvm. Does that mean that my sys-usb is a DisposableVM?

So how can I tell if the SD reader is USB or PCI? I know that there’s the lsusb command, but I can’t tell if the SD card reader is included as some of the names returned are rather undescriptive (e.g. Linux Foundation 2.0 Root Hub). I’m not sure if there’s a similar command to list PCI devices as well.

6

That is correct. Assuming you haven’t changed any of that yourself: you’ll observe that fedora-38-dvm is itself an appVM that is based on fedora-38 (a templateVM) and acts as “template for disposable VM” (dispVM) which is a checkbox that is enabled in the settings.

fedora-38          templateVM
|- fedora-38-dvm   appVM + template for dispVM
    |- sys-usb     dispVM

Note: your sys-usb is not called disp1234 because it is called… sys-usb! That makes it a “named disposable VM” which means that every time it is created again after being disposed it will get the same name. That is useful because you can refer to it by name instead of trying to guess if it is going to be disp1234 or disp4567 or any other number each time.

But despite that stable name, every time you restart sys-usb it is disposed of and a new one is created like for any other dispVM.

4 Likes
7

The one to which PCI USB controller is connected.

You can use qvm-pci list command in dom0 terminal to see your PCI devices. Or see them in Devices tab in Qube Settings.

1 Like
8

Thanks for the command. I used it and I’m fairly certain my SD card reader is among the PCI devices listed.
However, this seems more troublesome if it’s a PCI device. The Qubes documentation says that PCI devices are exposed to dom0. Wouldn’t that potentially compromise dom0 if I insert a compromised SD card into my computer?
I read some more and found a suggested solution:

The solution would be to hide the SD card reader from dom0 by having this line

GRUB_CMDLINE_LINUX="$GRUB_CMDLINE_LINUX rd.qubes_hide_all_usb rd.qubes.hide_pci={InsertPCINumberHere}"

in /etc/default/grub in dom0, and then attaching that PCI device to sys-usb, so it only ever makes contact with sys-usb.
I’m not familiar with tinkering in Qubes, or Linux in general, so I just wanted some affirmation if I’m going about this the right way and it won’t screw up my system.

9

After editing /etc/default/grub you’ll also need to run
grub2-mkconfig -o /boot/grub2/grub.cfg
for legacy bios or
grub2-mkconfig -o /boot/efi/EFI/qubes/grubx64.cfg
for UEFI.

There’s always a way to screw up something, for example if you get wrong PCI device number and hide different PCI device and not SD card reader.

10

In the dom0 terminal, right? And would you mind explaining what these commands do and why they’re needed?

1 Like
11

Yes.

GRUB 2 reads its configuration from the /boot/grub2/grub.cfg file. This file contains menu information.

The GRUB 2 configuration file, grub.cfg, is generated during installation, or by invoking the /usr/sbin/grub2-mkconfig utility, and is automatically updated by grubby each time a new kernel is installed. When regenerated manually using grub2-mkconfig, the file is generated according to the template files located in /etc/grub.d/, and custom settings in the /etc/default/grub file. Edits of grub.cfg will be lost any time grub2-mkconfig is used to regenerate the file, so care must be taken to reflect any manual changes in /etc/default/grub as well.

12

Would it hurt to run grub2-mkconfig twice to change the config files for both legacy bios and UEFI?

13

No, it won’t hurt.