To improve security against foreign devices connected to system without owner's permission, KDE should ask whether or not allow unknown device. This can be done using udev and 'authorized' attribute, or via /sys/bus/usb/devices/*/authorized file. Manual device authorization can prevent connecting hardware keyloggers or malicious flash drives to temporairly unattended devices, when attacker is not interrested in device itself but in user's data. Or at least make these attacks much harder. Of course this will require cooperation with some system services, but simple udev connector should do the trick. Something like this (source: https://www.abclinuxu.cz/blog/ucim_sa/2015/5/udev-nastaveni-povolenych-usb-zarizeni-whitelist#8): #Check USB HID devices ACTION=="add", ATTR{bInterfaceClass}=="03" RUN+="/usr/lib/kde4/libexec/authorize-usb" And the /usr/lib/kde4/libexec/authorize-usb would ask (via dbus or something) currently logged in user to authorize the device. This feature request originates from blog post at https://www.abclinuxu.cz/blog/ucim_sa/2015/5/udev-nastaveni-povolenych-usb-zarizeni-whitelist (czech; code listings should be understandable even without understanding the text around). Reproducible: Always
Hello, i'd like to mention the USBGuard project (https://github.com/dkopecek/usbguard) here, which solves the RFE described here and it has a Qt applet (https://github.com/dkopecek/usbguard-applet-qt/). It would be nice if the work invested in the project would be used to implement this RFE. I'm open to any suggestions and ideas, especially for the applet, which is probably of the most interest to the KDE users. I'm not a UI designer, so the applet as it is now is quite ugly. Anyway, bellow are some technical notes that apply to any implementation of USB device authorization in Linux. (In reply to Josef Kufner from comment #0) > To improve security against foreign devices connected to system without > owner's permission, KDE should ask whether or not allow unknown device. This > can be done using udev and 'authorized' attribute, or via > /sys/bus/usb/devices/*/authorized file. There's also a per-controller flag (/sys/bus/usb/devices/usbX/) authorized_default. As the name suggests, it sets the default value of the authorization state for newly inserted devices. This flag can be set either at run-time by writting to the file or using the usbcore kernel module parameter -- authorized_default. Using the later option would require help of an additional tool run at boot time to enable selected devices (i.e. USB keyboard to enter a password if the user uses one). > Manual device authorization can prevent connecting hardware keyloggers or > malicious flash drives to temporairly unattended devices, when attacker is > not interrested in device itself but in user's data. Or at least make these > attacks much harder. It also limits the attack surface on bugs in USB interface drivers. Unless you block modules that you really don't use, the USB device might cause to load an exotic/old module with bugs that might be exploitable from a USB device. > #Check USB HID devices > ACTION=="add", ATTR{bInterfaceClass}=="03" > RUN+="/usr/lib/kde4/libexec/authorize-usb" I don't think this particular example would work because at the moment the USB interfaces are instantiated (and an uevent is sent to udev), the underlying USB device is already authorized. You can deauthorize it, but there's some time frame for an attack in between. Implementing this correctly using just UDev rules requires help from external tools to at least parse the USB interface descriptors at the time the USB device is being handled. By parsing the descriptors, you will know what USB interfaces the device will create on the system.
Hello, recently, I've implemented a D-Bus interface in USBGuard. That should make the integration with it much easier for various desktop apps/environments. The interface is not set in stone yet, so if you are going to consider USBGuard to resolve this RFE and find out that the current interface has some design flaws, then I can implement additional features and make changes to it.