After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 556301 - Add mouse/keyboard pairing assistant
Add mouse/keyboard pairing assistant
Status: RESOLVED OBSOLETE
Product: gnome-bluetooth
Classification: Core
Component: general
unspecified
Other Linux
: Normal enhancement
: ---
Assigned To: gnome-bluetooth-general-maint@gnome.bugs
gnome-bluetooth-general-maint@gnome.bugs
Depends on: 575768
Blocks:
 
 
Reported: 2008-10-14 17:41 UTC by Bastien Nocera
Modified: 2019-03-20 10:34 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Bastien Nocera 2008-10-14 17:41:03 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
Comment 1 David Zeuthen (not reading bugmail) 2008-10-14 19:07:16 UTC
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.
Comment 2 Bastien Nocera 2008-10-14 19:51:21 UTC
(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
Comment 3 David Zeuthen (not reading bugmail) 2008-10-14 21:12:34 UTC
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!
Comment 4 Bastien Nocera 2008-10-15 21:57:44 UTC
Note for later, we should also discard internal keyboards and trackpads when the laptop is docked.
Comment 5 Bastien Nocera 2009-02-25 14:50:46 UTC
Reassigning to bluez-gnome fork, gnome-bluetooth.
Comment 6 Bastien Nocera 2009-03-23 16:58:34 UTC
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/
Comment 7 Bastien Nocera 2009-06-04 23:08:35 UTC
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.
Comment 8 Bastien Nocera 2012-02-01 15:45:48 UTC
Note, use the "Virtual Device" property to blacklist devices:
http://patchwork.freedesktop.org/patch/7690/
Comment 9 GNOME Infrastructure Team 2019-03-20 10:34:41 UTC
-- 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.