USB 'firewall'
Yes, udevs rules in Linux help but are not the complete answer to 'USB firewall', as Peter Gathercole points out, spoofing USB devices will malicioulsy provide legitimate Product ID and Vendor ID strings.
Nobody seems to have cottoned on to the fact that use of USB devices is inherently risky BY SPECIFICATION. The USB specification mandates that OS kernels (all of them) instantiate low level drivers upon detecting the connection of a USB device.
USB mass storage devices with on-stick µC are way more difficult to mitigate.
Being truly nerdy I once watched the Linux kernel generte all of: 'sgx', 'sdy' and 'sr0' upon connection of an Imation IronKey (sg is SCSI generic, sd is the flash mass storage bit & sr is a pseudoCD on the IK wherein stored all the code: no µC on the IK)
In Linux we can write udevs rules to 'white list' only those USB devices that we (would wish to) 'trust' by PID, VID (and even down to the granularity of Serial# if such is included in the USB parameter block offered by the device).
In Windows we need a COTS bolt-in to achieve the same function (because the Windoze Registry obfuscation of where the USB device Class and device-specific USB parameter block is stored is heinous and the coders of the COTS bolt-on have done all that 'heavy lifting' for us).
Then, to truly 'trust' the device you need to take the executable from a Known Good* one and 'fingerprint' it, e.g. take the SHA-256 hash of it.
Now, 'adopt' the executable -include it in your own software (which of course you measure before invoking, including measureent of the 'adopted' USB exe)
Then, adjust udevs rule to point to a script that ensures the 'internal' exe is invoked not the 'on stick' exe
I am not sure how this last bit is accomplished on M$, but a PowerScript guru would achieve it
* i.e. not 'as previously enjoyed by NSA' & not using on-stick µC
Biting the hand that feeds IT
