I would like to understand the rationale behind Qubes 4.3 disallowing opening drives in sys-usb? This was possible in prior Qubes OS versions. I was under the impression that it is more secure to copy a file from a drive attached to sys-usb rather than attaching that same drive to an AppVM. Was I wrong? What are the risks of allowing sys-usb to mount drives as described here:
Hi.
sys-usb has generally PCI USB controllers attached to it. Which could have more than one port. Let’s assume user connects a trusted USB drive (e.g. containing some sensitive files) to one port. In the same time, another port has some malicious HID controller or network controller attached to it. O.MG cable is one of such covert data collection and exfiltration devices. In such scenario, the exfiltration device would be hypothetically able to mount & read sensitive information from that drive and send it to bad actors.
I think, that lowers the possible attack vector.
Sys-usb services all usb devices to all other App Qubes. If an attacker can successfully compromise sys-usb, he has the ability to attack all other devices, that sys-usb handles.
If an attacker attacks an App Qube directly via a malicious USB-drive, he has only access to that App Qube (and their attached USB-Devices), not to all USB-Devices, that are managed by sys-usb.
I have a standard sys-usb based on debian-13-xfce, with minimal-usbvm
enabled, and have no issue in mounting attached USB devices. Never
thought about it - perhaps I should.
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
Thank you for your replies @unman @murdock @alimirjamali
I understand that the developers of Qubes OS have to make design and usability decisions based on various, sometimes contradictory, threat models. Maybe in the future, if resources allow, Qubes developers could give users the ability to make some of these decisions during the installation process or immediately after installation. Many users on this forum, including myself, have raised questions on how to attach devices including Android phones.
I’ve thought about it. Can someone explain to me in what way they are
unable to mount USB drives in sys-usb?
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
@unman this is one more post discussing this issue:
By default, you will will an error message if you try to mount a USB drive. I solved it by unchecking minimal-usb VM under services in sys-usb settings, in a Fedora-based sys-usb.
Do you mean that file managers won’t automatically mount drives or that any mounting (e.g. #mount /path/to/partition /path/to/mount/point) won’t work?
Off-topic slightly, but I for one would love to have all mounting/USB devices disabled on sys-usb, ideally with any action to mount triggering a dispvm. It would still have to be possible for devices to be shown as they are in the devices widget though, making this behavior complicated.
This will work (with sudo). But if the template does not have passwordless sudo, even that won’t work
What? Of course not. But this is the case for any qube which doesnt
have passwordless root. In that case one either opens a root terminal in
sys-usb to run mount , or qvm-run -u root sys-usb 'mount /dev/sda1 /mnt'
The point is that this thread and the other guide is misplaced. The
developers have not removed the ability to mount drives. The minimal-usb
service stops some services from running in sys-usb - it doesnt stop you
from mounting partitions. It’s important to be clear about this.
Excellent to hear about this. It would be very nice if the ability to mount drives directly within sys-usb is restored. It will be very helpful to me.
I think this may get to the core of the problem here. I work mainly at
CLI for reasons, and so I have the ability to mount drives directly, as
before. I assume that by “directly” you mean “run a GUI that has some
mechanism for mounting” - that seems less direct to me.
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
Yes. Like that. For example for backing up to USB drives attached to sys-usb, or restoring from USB drives attached to sys-usb. Directly from Backup GUI and Restore GUI. Without any CLI intervention.
For me personally, I did not care about the issue that much. While I was aware of it for a very long time. Since I also used CLI workarounds.