GNOME Bugzilla – Bug 556301
Add mouse/keyboard pairing assistant
Last modified: 2019-03-20 10:34:41 UTC
In the form of an applet, for GDM to use. For mice: - check whether there is a mouse available through hal (has "info.capabilities" = "input.mouse", and isn't "Macintosh mouse button emulation"). - popup window saying no mouse is available, and ask user to turn the Bluetooth mouse on - list all the discoverable devices, and when a mouse that's not paired/trusted is available, try to pair with it using "0000" as the pin - dismiss dialogue automatically if any mouse is plugged in/already paired and turned on For keyboards: - check whether there is a keyboard available through hal (has "info.capabilities" = "input.keyboard"). - popup window saying no keyboard is available, and ask user to turn the Bluetooth keyboard on - list all the discoverable devices, and when a keyboard that's not paired/trusted is available, try to pair with it after generating a PIN code, and the pin is entered on the keyboard side. - dismiss dialogue automatically if any mouse is plugged in/already paired and turned on
Paired devices is not a per-user resource is it? IIRC it's system wide. So if you pair a device at the login screen, it can be used to control any login session too, right? The feature seems useful to me, but I'm concerned about the security implications here. What prevents an attacker from sneaking up on a workstation that shows the login screen and pair a keyboard? Probably nothing. And the attacker can't do much, he would have to be in range to perform an attack... an even if he's in the neighboring cubicle there's not a lot he can do.
(In reply to comment #1) > Paired devices is not a per-user resource is it? IIRC it's system wide. So if > you pair a device at the login screen, it can be used to control any login > session too, right? Yes. > The feature seems useful to me, but I'm concerned about the security > implications here. What prevents an attacker from sneaking up on a workstation > that shows the login screen and pair a keyboard? Probably nothing. 2 things. They would need to unplug/disable the existing devices, the admin would need to have the feature enabled (on most shared machines where there could be such attacks, Bluetooth is usually disabled/unavailable, admins would lock down the desktop). > And the > attacker can't do much, he would have to be in range to perform an attack... an > even if he's in the neighboring cubicle there's not a lot he can do. 10 meters. We could certainly show whether a Bluetooth keyboard/mouse is being used to avoid this scenario (a status icon?): - Bluetooth is enabled, feature is enabled - at the login screen, unplug the wired keyboard/mouse - pair the Bluetooth device(s) - replug the wired devices - play with people's sanity with the remote keyboard/mouse
Yeah, providing a way to lock this down sounds like a good idea. I'm not sure we need a status icon; maybe just a notification bubble on the first login when using a new BT device? Either way, since the attacker is within stabbing range (10 meters) I'm not sure it's going to be a problem in real life. So no security concerns from me with this approach; seems like a great feature to have!
Note for later, we should also discard internal keyboards and trackpads when the laptop is docked.
Reassigning to bluez-gnome fork, gnome-bluetooth.
This should be a pretty straight forward thing to hack on for a new contributor. The code would live under wizard/. This also needs an additional preference in the properties app: http://people.fedoraproject.org/~hadess/bluetooth-pairing-assistant/
Note that this should be using GTK+'s xinput support to detect the devices. This should be based on the XI2 GTK+ work, but as we don't have a bug opened for that, making it depend on XInput hot-plug support in GDK instead.
Note, use the "Virtual Device" property to blacklist devices: http://patchwork.freedesktop.org/patch/7690/
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnome-bluetooth/issues/8.