Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp657023pxk; Thu, 24 Sep 2020 15:13:07 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxukdQYLZ4PCf0fo3bsPyjTlX5j1XG27+2j6remLW2+4Vrdxn4s+p0Gd9uDG07LX48XGJfD X-Received: by 2002:aa7:c256:: with SMTP id y22mr957885edo.16.1600985586909; Thu, 24 Sep 2020 15:13:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1600985586; cv=none; d=google.com; s=arc-20160816; b=dtBIg5yjBCu1pO1qhdYwuFJ4t4MTukh9T4jO3V+N3Rs00w6vwc6OkyQcIY3Ep0boWm WULikHllDwNUbxCz1uS51i4WaiiEYPsgqg6Ajz8G7zF82sT87DyoM7v5mzuJJ1vT12fd zpKWT9HzZfMnKol77R0xgI1UgCd2xqVFFDtp5hl+4oKTuGoqiYCdHK7m2lCU+jqlDyP0 om86DJb7Fuaj5+Oevw/6mBX2TGxAhqFRB0EzS1UKxYj4xk6adZ4l9Lo0iguHQTayb7pf 6Tmd/e11J8leXlyev3iJAB6aTE/siZCti2eoKriNqn2XPUEmQ7+0XmCpdR6PkOtiaY73 EMeg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=fTUajlSQAutv76s4VWigr/EvtqNy5/f5iICcF4dhbA0=; b=nGmLyUh+EdQKOEICxaTYIs1VhaPgtdUhi02ULf+07C/rpvcS0YBJEQgLRXe9LPZDX2 JDd++Yb0ofU9f7k83N1s3QWKJI7uWid5/U1MuwluD3bnUnlmA8OpN1PuZzrvPOxnU+OZ djI2qzCUqvKSAZxf4RupNhrymNHOASpc02OqUdrS9+DUaEpug2+FjC96NF1i+LzVomt4 Gct2EN0HmOYJZ4o/t5TXvCBQPbP2C9QvynuB6ADgw70gHCTFyjtImt9ZxQM/RRXm/prN qGb2LSdKe4fBdF1MgmdUZgEtloRFF63j9LFXcY10n+1fUxUsFR6HrGPqxQ+yBT+GEpOa rA2A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=j87FngmA; spf=pass (google.com: domain of linux-bluetooth-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-bluetooth-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id lc20si556464ejb.534.2020.09.24.15.12.29; Thu, 24 Sep 2020 15:13:06 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-bluetooth-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=j87FngmA; spf=pass (google.com: domain of linux-bluetooth-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-bluetooth-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726559AbgIXWMN (ORCPT + 99 others); Thu, 24 Sep 2020 18:12:13 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44612 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726205AbgIXWMN (ORCPT ); Thu, 24 Sep 2020 18:12:13 -0400 Received: from mail-oi1-x242.google.com (mail-oi1-x242.google.com [IPv6:2607:f8b0:4864:20::242]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3731FC0613CE for ; Thu, 24 Sep 2020 15:12:13 -0700 (PDT) Received: by mail-oi1-x242.google.com with SMTP id t76so669077oif.7 for ; Thu, 24 Sep 2020 15:12:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fTUajlSQAutv76s4VWigr/EvtqNy5/f5iICcF4dhbA0=; b=j87FngmAstYZVuMmzt35BveN4yGR9CQo71N/KBv/95Z7KN+VWeoeTdgqwL7SXbhJJy b5sGL+BqFKQzGhk5J2vIS0DFkeu3AGBF5x51cgwYiDo9JqvW2IljvFdv4xDUdc0xqMgD I2+l6EG7ftEcfRb10S3FudcVdFqpKJSO5BHBAKJV3VNvL0NyXz+Dr3aF2+BxhaixAUs2 4/kdBKCk+ja9UZqIUCYX4ulXluORXjY7VtZuVevrKtj2UQFJD2/XpMenop/h+v/MNQr6 OngriykQ2fluTvNQiXjFuDKqqFzMlJjUIEAlUp9MUb0bIP02gdpG5MkB+hCxCCnpX1Ly gpJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=fTUajlSQAutv76s4VWigr/EvtqNy5/f5iICcF4dhbA0=; b=sOP1tI0ghYDAMkXjPdWy6go8wp8JDGIt/h/0yX2hP57q74KZ6YgZreMIMSLtVO0ahc tnS7SlbfmMhg3okSroXDgv5jwfgHUEHeXSCKU/u0lWx0lRAo99KIQv+KQi/Xe3GFejvf F1V0ezpS9Ecq0ix2J0XOf74MPNpSdN4PiY4vxosSn/T1KKk9eOCzPh628Is7sTQhRuKO 8ubM68OY3bRvCDqmgj4lX/wXMN29ufdVYdTrRZpRx5cT3sOoDRNgN3ptIBGVcDusNzOM g9hkNhMLf+8RbeAa2MhbRhvmF2eNgbYhi97+yj28loxbfi/otDzOxUoouwUwu/253FGb nZcA== X-Gm-Message-State: AOAM530K9p/BerC5iFBjX2t9UnpXuG1RdYuhru4HuBv1IpbVJRyJeBrm EvBEqNnPbRYId6vHtw8wrp0pTD06kV7fSR8omvk= X-Received: by 2002:aca:1b01:: with SMTP id b1mr571024oib.137.1600985532511; Thu, 24 Sep 2020 15:12:12 -0700 (PDT) MIME-Version: 1.0 References: <20200924140527.Bluez.v1.1.Iedecbb8c8ebb111b14206dddc5bea3c40dfa1771@changeid> In-Reply-To: From: Luiz Augusto von Dentz Date: Thu, 24 Sep 2020 15:12:00 -0700 Message-ID: Subject: Re: [Bluez PATCH v1] device: Disable auto connect when pairing failed To: Yu Liu Cc: "linux-bluetooth@vger.kernel.org" Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-bluetooth@vger.kernel.org Hi Yu Liu, On Thu, Sep 24, 2020 at 2:50 PM Yu Liu wrote: > > Hi Luiz, > > I was thinking about putting this into btd_device_set_temporary as well, so as the short term solution you think this should be the way to go while we look into only making trusted devices auto connectable? I can make the change then. Yep, lets have it as part of btd_device_set_temporary first. > On Thu, Sep 24, 2020 at 2:40 PM Luiz Augusto von Dentz wrote: >> >> Hi Yu Liu, >> >> On Thu, Sep 24, 2020 at 2:08 PM Yu Liu wrote: >> > >> > When connecting a LE keyboard, if the user input the wrong passkey, the >> > stack would keep auto connect and thus allow the user to retry the >> > passkey indefinitely which is a security concern. This fix would >> > disallow the auto connect if the authentication failed. >> > >> > --- >> > >> > Changes in v1: >> > - Initial change >> > >> > src/device.c | 10 ++++++++-- >> > 1 file changed, 8 insertions(+), 2 deletions(-) >> > >> > diff --git a/src/device.c b/src/device.c >> > index a4b5968d4..764cca60e 100644 >> > --- a/src/device.c >> > +++ b/src/device.c >> > @@ -6033,11 +6033,17 @@ void device_bonding_complete(struct btd_device *device, uint8_t bdaddr_type, >> > device_cancel_authentication(device, TRUE); >> > >> > /* Put the device back to the temporary state so that it will be >> > - * treated as a newly discovered device. >> > + * treated as a newly discovered device; also disable auto >> > + * connect. >> > */ >> > if (!device_is_paired(device, bdaddr_type) && >> > - !device_is_trusted(device)) >> > + !device_is_trusted(device)) { >> > btd_device_set_temporary(device, true); >> > + if (device->auto_connect) { >> > + device->disable_auto_connect = TRUE; >> > + device_set_auto_connect(device, FALSE); >> > + } >> > + } >> >> While this looks correct we could perhaps design it in such a way that >> only trusted device are allowed to set auto connect, though that may >> need a lot more changes than this one so I would be fine applying this >> so we can think about the implications, also perhaps this should be >> incorporated to btd_device_set_temporary since a temporary device >> should probably not be left in to auto-connect and only a user action >> to attempt to use it again to restore its auto connect status. >> >> To summarize we should answer 2 questions: >> >> 1. Should an untrusted device be allowed to be marked as auto-connect? >> Maybe, though we didn't consider trusted property for auto-connect, >> but I think using it might make auto-connect more predictable to the >> upper layer. >> 2. Should a temporary device be allowed to be marked as auto-connect? >> Most likely not, it should be removed if the user doesn't take any >> action during the temporary grace period. >> >> > device_bonding_failed(device, status); >> > return; >> > -- >> > 2.28.0.681.g6f77f65b4e-goog >> > >> >> >> -- >> Luiz Augusto von Dentz -- Luiz Augusto von Dentz