Always-offline USB-qube or printer/scanner qube can go online when adding PCI card or changing their places (security)

[jamke]

How to file a helpful issue

Qubes OS release

R4.1.1.

Brief summary

Always-offline USB-qube can get online when adding PCI card or changing their places (security flaw).

Background

The fact that Qubes OS identifies PCI device only using some bus index is well known and is a very bad approach.
Simple switch slots of PCI devices inside PC or adding/removing PCI devices can easily make the even clean system unbootable. In 50% of cases the internet access will be broken.
Also backup recovering of qubes that use PCI can lead to the same problems.
But this issue-ticket is created to reflect a security downside of current PCI device identification in Qubes.

Steps to reproduce

1. Manually create a usb qube and assign it with a USB Controller.
2. Set it to be strictly offline - have no net-qube (may even use qvm-firewall to disable any traffic?).
3. Turn PC off
4. Switch cards in PCI slots or add new ones.

Expected behavior

The created usb qube stays completely offline.

Actual behavior

Depending on numeration of PCI devices in dom0 you may easily get into the situation that offline qubes that acquire PCI devices (USB Controllers as in case of USB-qube) can get Ethernet controller instead of their devices. I think it can allow them to instantly go online and breach the security of offline-qube.
In other words, qubes that are excepted to be as offline as vault will become as online as sys-net.
To my opinion it's completely unacceptable from the security point of view.

Additional problems

Another case of security breach is when USB qube or printer/scanner qube get a access to some different thing that it is not supposed to have. E.g. scanner qube that is connected to USB Controller that is connected ONLY to a scanner - can get different USB Controller and get access to all connected flash-drives inserted. Or get access to some USB private device or something else.

Workaround

I personally see 2 possible workarounds for an average user:

1. When something is changed in the PCI configuration of PC - at the first boot user must intervene in the boot process and start PC with a kernel parameter qubes.skip_autostart as it is describe here:
   https://www.qubes-os.org/doc/autostart-troubleshooting/
   After the boot of Qubes OS domain dom0 should be the only running qube, the user must check the settings of all qubes that have PCI connected (usb qubes, printer or scanner qubes and other specific ones and sys-net and other net qubes) to manually check and set PCI devices to all those qubes according to the new device numeration.

2. When something is changed in the PCI configuration of PC - before the first boot user must physically disconnect all the ethernet and other cables that allow to go online or do something undesired. After turning the computer on the user must do all the action mentioned in the previous paragraph. It will require them to turn some qubes off as PCI can be change only for powered off qubes.

The way it can be fixed

1. First and the best option is to make a proper identification of PCI device, not serial bus slot only but proper way including name or serial number. At least to somehow disable devices that changed their names.

2. Maybe the qube should have some "offline" flag in prefs. So, sys-net will have no flag but still no Net qube assigned, whilst vault and usb qubes will have this flag and will have no ability to use internet because of some kernel module is deactivated or something. Not a full bullet-prove solution but at least user will have some sub-guarantee that their offline qube will not suddenly become open to the web.

[DemiMarie]

I wonder if the PCIe Location Path (whatever it is) should be used instead. That is what Hyper-V Discrete Device Assignment uses at least. Device name and serial number have the drawback that they can be spoofed, which could be a problem if AEM is in use.

[jamke]

The combination can be used. E.g. current bus index and the name will already solve a lot of cases of wrong pci-device attachments on boot.
It will not solve more rare case of 2 devices with the same name (model), when one still mistakenly replace another in the VM, so some serial number is still required. But still, even additional checks for the device name would be a big step forward.

[unman]

Is this not duplicate of #7792?

[andrewdavidwong]

Is this not duplicate of #7792?

This appears to be a duplicate of an existing issue. If so, please comment on the appropriate existing issue instead. If anyone believes this is not really a duplicate, please leave a comment briefly explaining why. We'll be happy to take another look and, if appropriate, reopen this issue. Thank you.