search

6E006B / usbguard-gnome

GNOME interface for USBGuard with the aim to be intuitive, informative and as low interaction as possible.
12 stars 5 forks source link

Added smart keyboard interaction. Prevents users from unlocking thems… #10

Closed Thorsten-Sick closed 6 years ago

Thorsten-Sick commented 6 years ago

…elves on total keyboard destruction by coffee.

Some things do not yet work as expected. So there is a wishlist:

6E006B commented 6 years ago

While looking through the code I might have found a problem with the proposed implementation: If you automatically enable the device if it is plugged in, if it has a configuration containing device class 0x3 (HID), that also means, that you activate all other configurations (and therefore device classes) as well. Therefore attacks based on any other device class is enabled through this kind of behavior. A possible work around could be to check if it is the only type of device class the USB device has. Selectively enabling only the HID configuration is not possible as far as I know.

Thorsten-Sick commented 6 years ago

You are right. And there is no selective approach. What if: We automatically activate HID-ONLY devices ? As soon as it is a bit smarter and offers other features it will not be added automatically.

In the case of broken keyboard: User will have to get a simple replacement keyboard.

Thorsten-Sick commented 6 years ago

Changed the logic to only accept pure keyboards

6E006B commented 6 years ago

As a feature request I would like to propose to check if the screen is actually locked before allowing the device. For one to circumvent race conditions and also, if the user does not use a lock screen application listening for dbus events, the device is not enabled with no lock screen in place at all. You think this can be added easily or should this be handled in a different branch?

Thorsten-Sick commented 6 years ago

I'll add this today. The sleep was meant to give the user the opportunity to notify the notification. As the lock screen does not show notifications (yes, I know, dirty hack).

As for race conditions with the attack: When inserting a BashBunny it needs some seconds to boot. After that it registers as a keyboard and after some (configurable) seconds it starts to attack. If the keyboard is not registered until the attack starts the attack will evaporate. User is protected. So there is a race condition, but a good one. Just sad that the attack delay in the BashBunny can be configured....or it would be a simple mitigation (not perfect but ok).

Thorsten-Sick commented 6 years ago

Fixed it to using events (screensaver lock) to activate the devices. Can be pulled now (IMHO).