RE: [PATCH] Bluetooth: Fix to auto accept pairing request for no MITM case

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Johan,

-----Original Message-----
From: Johan Hedberg [mailto:johan.hedberg@xxxxxxxxx] 
Sent: Monday, March 31, 2014 3:20 PM
To: Marcel Holtmann
Cc: Hirenkumar Tandel; Bing Zhao; linux-bluetooth@xxxxxxxxxxxxxxx; Gustavo F. Padovan; Rahul Tank; Quinton Yuan
Subject: Re: [PATCH] Bluetooth: Fix to auto accept pairing request for no MITM case

Hi Marcel,

On Mon, Mar 31, 2014, Marcel Holtmann wrote:
> >>>> --- a/net/bluetooth/hci_event.c
> >>>> +++ b/net/bluetooth/hci_event.c
> >>>> @@ -3239,8 +3239,13 @@ static void 
> >>>> hci_user_confirm_request_evt(struct
> >>>> hci_dev *hdev,
> >>>> 
> >>>> 		/* If we're not the initiators request authorization to
> >>>> 		 * proceed from user space (mgmt_user_confirm with
> >>>> -		 * confirm_hint set to 1). */
> >>>> -		if (!test_bit(HCI_CONN_AUTH_PEND, &conn->flags)) {
> >>>> +		 * confirm_hint set to 1).
> >>>> +		 * But if local host has NoInputNoOutput capability,
> >>>> +		 * then no use of passing request to user space,
> >>>> +		 * so go ahead with auto accept.
> >>>> +		 */
> >>>> +		if (!test_bit(HCI_CONN_AUTH_PEND, &conn->flags) &&
> >>>> +		    conn->io_capability != HCI_IO_NO_INPUT_OUTPUT) {
> >>>> 			BT_DBG("Confirming auto-accept as acceptor");
> >>>> 			confirm_hint = 1;
> >>>> 			goto confirm;
> >>> 
> >>> So basically this changes the policy from rejecting pairings when 
> >>> an agent is not registered to accepting them in case it's a 
> >>> just-works pairing? I'm not convinced we want to do such a policy 
> >>> change that relaxes security in this regard.
> >>> 
> >>> Do you have an actual product use case for this? What's the 
> >>> background and reasoning behind it?
> >> 
> >> A use case is for chrome book, for user not logged in case, 
> >> Bluetooth is working at this time, but default-agent is not 
> >> registered, however user will expect  Bluetooth to work for certain 
> >> simple devices like mouse.
> > 
> > I still don't completely understand this. If the user has paired the 
> > mouse previously (which must be the case since otherwise the mouse 
> > would not be connecting to the PC) then there will not be any user 
> > confirm request during the connection creation.
> 
> actually bluetoothd must be running to accept an incoming connection 
> from a HID device. The initial connection handling is done in 
> bluetoothd. Also without bluetoothd running, you do not have page scan 
> enabled either. The kernel starts out with page scan disabled.

Sure, but if I understand the situation here bluetoothd *is* already running at the login prompt stage but there is no agent registered. In such a case I think it should be fine to accept connections from already paired and trusted devices but we should probably keep rejecting them from any other device (even if the pairing would trigger just-works).

We are ok to drop this patch if, without agent registered, it is not comfortable to allow incoming pairing which even ask for just work model.

Johan

Thanks,
Hiren
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Bluez Devel]     [Linux Wireless Networking]     [Linux Wireless Personal Area Networking]     [Linux ATH6KL]     [Linux USB Devel]     [Linux Media Drivers]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Big List of Linux Books]

  Powered by Linux