Blockers before this can be worked at:
Things which can be done before this gets important:
Could you please describe what kind of attack you mean or give an example?
An USB device gets attached which then exploits a vulnerability in the kernel?
The connection of an untrusted USB device to dom0 is a security risk since the device can attack an arbitrary USB driver (which are included in the linux kernel), exploit bugs during partition-table-parsing or simply pretend to be a keyboard. There are many ready-to-use implementations of such attacks, e.g. a USB Rubber Ducky. The whole USB stack is put to work to parse the data presented by the USB device in order to determine if it is a USB mass storage device, to read its configuration, etc. This happens even if the drive is then assigned and mounted in another qube.
To avoid this risk, use a USB qube.
Attaching a USB device to a VM (USB passthrough) will expose your target qube to most of the security issues associated with the USB-stack. If possible, use a method specific for particular device type (for example, block devices described above), instead of this generic one.
Or USB Rubber Ducky?
Which classes of attack is this supposed to prevent?
Implies that there is some kind of per VM filtering? How does that work?
It denies “new USB”. How are “old USB” configured? How would users allow an USB device?
No, not necessarily.
There is no such thing as “restrictions we have” related to USB. The only conscious change was thunar USB auto mounting disabling.
Otherwise “restrictions we have” is technically undefined. It’s not yet clear what causes these issues. Therefore “don’t do what we do now” and “do it as in this thread” isn’t possible because “don’t do what we do now” prerequisites knowledge of “what do we do now?”.
“don’t do what we do now” also mixes together security hardening changes which were applied for reason totally unrelated to USB such as proc-hidepid.
There is no way to skip the details of this forum thread Disk & USB Automount in Kicksecure and to generally say “doing as in this thread is better”.
I wouldn’t underestimate the difficulty of what is proposed in this forum thread either. I haven’t used this yet but looking at the documentation here (says “As of Jan 31, 2019, the information in this section has been deprecated. It may or may not be relevant for contemporary usage. Handle with care!”) does not look trivial either: