Hi Johan, -----Original Message----- From: Johan Hedberg [mailto:johan.hedberg@xxxxxxxxx] Sent: Saturday, March 29, 2014 12:54 PM To: Bing Zhao Cc: linux-bluetooth@xxxxxxxxxxxxxxx; Marcel Holtmann; Gustavo Padovan; Hirenkumar Tandel; Rahul Tank; Quinton Yuan Subject: Re: [PATCH] Bluetooth: Fix to auto accept pairing request for no MITM case Hi, On Wed, Feb 05, 2014, Bing Zhao wrote: > With existing implementation, during incoming SSP if no side requires > MITM protection, user confirm request event is forwarded to user space > for further user confirmation without checking io capability of local > host. But in case if there is no agent registered with bluez user > space daemon which means device has NoInputNoOutput capability at that > moment, it rejects the request. > > This patch will check for io capability of local host before > forwarding request to user space. If local host has NoInputNoOutput > capability, there is no point in forwarding request to user space. > Hence local host kernel goes ahead with auto accept, by sending User > Confirmation Request Reply command. > > Signed-off-by: Hiren Tandel <hirent@xxxxxxxxxxx> > Signed-off-by: Rahul Tank <rahult@xxxxxxxxxxx> > Signed-off-by: Quinton Yuan <qyuan@xxxxxxxxxxx> > Signed-off-by: Bing Zhao <bzhao@xxxxxxxxxxx> > --- > net/bluetooth/hci_event.c | 9 +++++++-- > 1 file changed, 7 insertions(+), 2 deletions(-) > > diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c > index d2c6878..b61f0c6 100644 > --- 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? [Hiren]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. 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
