On 2020-04-13 10:22 a.m., Dianne Skoll wrote: > On 2020-04-13 10:10, Peter Sjöberg wrote: > >> How can I prevent some generic qr scanners from sending anything else >> than [A-Za-z0-9] while still allowing a normal keyboard to be connected >> by some tech servicing the machine? > > You can't easily. One way I can think to do it would be to have some > embedded device in the middle that acts as a USB host to the QR > scanner, and a USB device to the real PC, and then filters what the > scanner can send. You could, for example, put a recent Raspberry Pi 4 > in between the scanner and the PC. Accept input from the scanner, > filter it, and then use Linux's USB gadget framework to talk to the > PC. > > https://www.hardill.me.uk/wordpress/2019/11/02/pi4-usb-c-gadget/ I'm sorry to say that hw solution is not an option. The BTM is spread out all over the world. It been hard enough to send a USB stick with the clonzilla image to them (now moved to google drive), sending some piece of hardware just won't work. My current thinking/hope: We don't always need a local keyboard and we do have ssh access so maybe blacklist usbhid (or whatever is the correct module). Then some attack vectors are blocked since even when you have a local keyboard it's locked down with 2fa and more. Blacklisting usbhid would block the qr scanner from behaving as a keyboard during bootup (after for example a power cycle) and make it harder to break in. Then to use it the app loads the module just during the time scanning happens. Next thing I hoped on was to be able to do something during usb enumeration, something so it goes in to a "text only" mode (did see something about mode1 vs mode2). While I do have the option of forking usbhid and making a special usbhidscanner module that path would be way to much work so unless it's already part of the kernel that is not going to happen. /ps > > You might be able to do it without another device if you can detach the > QR scanner from being handled by the kernel, and handle it yourself > with libusb, but that might not be so easy because then you somehow > have to re-inject the keyboard events into the input system. > > Regards, > > Dianne. > > To unsubscribe send a blank message to linux+unsubscribe [ at ] linux-ottawa [ dot ] org > To get help send a blank message to linux+help [ at ] linux-ottawa [ dot ] org > To visit the archives: https://lists.linux-ottawa.org > To unsubscribe send a blank message to linux+unsubscribe [ at ] linux-ottawa [ dot ] org To get help send a blank message to linux+help [ at ] linux-ottawa [ dot ] org To visit the archives: https://lists.linux-ottawa.org