From nobody Mon Jan 08 18:39:32 2024 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4T82ss6Ln7z56PJl for ; Mon, 8 Jan 2024 18:39:45 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [IPv6:2a00:1450:4864:20::630]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4T82ss4CTwz494D for ; Mon, 8 Jan 2024 18:39:45 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ej1-x630.google.com with SMTP id a640c23a62f3a-a298accc440so234317866b.1 for ; Mon, 08 Jan 2024 10:39:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1704739183; x=1705343983; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=ryFulrrwf6lelSA8uBVun24Ta6zslURMNaFZRAAGlVo=; b=jlxUt7SPAcW9hQAniKuWuL/2LLsEnkJxE646NE5VUqu8XdLRw1iGaXw1nDPpNXHYDJ Hv235TgLPNQUuCMmYJZsNLEcaAQ5Cm/Mb0kHqEvHT4e7ImqlgK4ddoblvWtu5A+/NNxs AGBzGmFoeUpOyTCiPCW03ar9YY9qBZVaHe9ljAzBL4M7AM3TudNiNajy3gs+VNf3TCva sN435Me0Vq4y8bz2EVkpVrguGUEpydygkc0VGpAlV5ppWev/tjyfIiz7l9kyjoNugH8n lc4tdqirMZO+5a0Zu7nUxDgZpsII73jaVjiomk1R8rBQWJ3WY0cuzcRjBWi1OuEZ6B7I WdwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704739183; x=1705343983; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=ryFulrrwf6lelSA8uBVun24Ta6zslURMNaFZRAAGlVo=; b=qNlHEPCuVtp6xZ1ZODDLOveDUGpQ9tiDp3W/Nuzd77WUC0i7YYHz4xBuPSoTAEyJy4 1sD1kXnD8IcB5owV5Hj8Gi8H6TPJG8pSZfZXvqNdRAHdn7Duw4OaFPz6rCD/swT62VCP yflENeMNH8veSc/1M3zAquUpPRMjzDJvpHXtSryEKzpi51isNPLBf3nkE5nVx2LR6t78 WSiZ9dYPaqT9vZ3/r5uXdJngsGPuxB4psVqCLyMjLhd4mftSON7CRzBvgTzH2yEcc4RZ 7eYg89bigXlOpMZ8N5LgfCn9/NV4EliHvu35p5VunDZHeJfupRdXAd+KHu6u7z35bqFw LSDQ== X-Gm-Message-State: AOJu0Yzv+X59k0bThW9aUGQ66Vf9cW0KIANz9/TFGGnihF+ngJc7q6RM pMhEray9PYYy0yJKzTBX1Shnd5szPGerPnCJBxHHVvU51UJ5Nmdc+GMAxDf1bog= X-Google-Smtp-Source: AGHT+IE3eScMW2hovE4adEARRKbiRySRQO6WJGK77lQHPz46izqplwJSLsD59//HYghkJXfG3E7Z2J4GGD27N7Nn6Ag= X-Received: by 2002:a17:907:b9cc:b0:a28:d5f4:ff48 with SMTP id xa12-20020a170907b9cc00b00a28d5f4ff48mr1851036ejc.116.1704739183647; Mon, 08 Jan 2024 10:39:43 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Mon, 8 Jan 2024 11:39:32 -0700 Message-ID: Subject: Re: Move u2f-devd into base? To: Xin LI Cc: Christian Weisgerber , FreeBSD Current Content-Type: multipart/alternative; boundary="00000000000079eb54060e7385d7" X-Rspamd-Queue-Id: 4T82ss4CTwz494D X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] --00000000000079eb54060e7385d7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jan 8, 2024 at 10:30=E2=80=AFAM Xin LI wrote: > On Mon, Jan 8, 2024 at 7:19=E2=80=AFAM Warner Losh wrote= : > >> On Mon, Jan 8, 2024, 7:55=E2=80=AFAM Christian Weisgerber >> wrote: >> >>> We have FIDO/U2F support for SSH in base. >>> >>> We also have a group "u2f", 116, in the default /etc/group file. >>> >>> Why do we keep the devd configuration (to chgrp the device nodes) >>> in a port, security/u2f-devd? Can't we just add this to base, too? >>> It's just another devd configuration file. >>> >> >> This properly belongs to devfs.conf no? Otherwise it's a race... >> > > That's a good point. But I think in practice the race (if I'm > understanding correctly, there would be a window where the device node > showed up, but with the standard permissions until devd kicks in and runs > "action" steps to change it) would probably not matter because the > consumers (Chromium?) would be polling for the device and when opening > failed, they would retry, as the security key is not guaranteed to be > present when a website asks for it, and it's perfectly natural for the > browser to see the security key getting attached and detached while it is > running. > I just don't like this depending on devd not dropping the arrival bit (due to too much congestion of events) and having a resulting broken system. It's half-assed today, but it's half-assed enough that it works enough of the time the issue hasn't been pressing (which is my way of agreeing with you: its imperfect, but it works almost all the time today). Working well enough suggests we shouldn't 'gate' this change to a perfect solution.... Especially since we're a bit short handed in the usb world after Hans' tragic passing. > I would say it's a good idea to have something there in place to support > these security keys (possibly also cameras, etc.), especially considering > the base OpenSSH now supports U2F devices. It's probably a good idea to > have adduser / installer to have a defined "interactive local user" group= s > (u2f, video, etc. come to mind) that users are added into by default to > provide a reasonable out-of-box default too. > Totally agree here. Warner --00000000000079eb54060e7385d7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Jan 8, 2024 at 10:30=E2=80=AF= AM Xin LI <delphij@gmail.com>= ; wrote:
On M= on, Jan 8, 2024 at 7:19=E2=80=AFAM Warner Losh <imp@bsdimp.com> wrote:
On Mon, Jan 8, 2024, 7:5= 5=E2=80=AFAM Christian Weisgerber <naddy@mips.inka.de> wrote:
We have FIDO/U2F support for SSH in ba= se.

We also have a group "u2f", 116, in the default /etc/group file.<= br>
Why do we keep the devd configuration (to chgrp the device nodes)
in a port, security/u2f-devd?=C2=A0 Can't we just add this to base, too= ?
It's just another devd configuration file.
=

This properly belongs to devf= s.conf no? Otherwise it's a race...

That's a good point.= =C2=A0 But I think in practice the race (if I'm understanding correctly= , there would be a window where the device node showed up, but with the sta= ndard permissions until devd kicks in and runs "action" steps to = change it) would probably not matter because the consumers (Chromium?) woul= d be polling for the device and when opening failed, they would retry, as t= he security key is not guaranteed to be present when a website asks for it,= =C2=A0and it's perfectly natural for the browser to see the security ke= y getting attached and detached while it is running.

I just don't like this depending on devd no= t dropping the arrival bit (due to too much congestion of events) and havin= g a resulting broken system. It's half-assed today, but it's half-a= ssed enough that it works enough of the time the issue hasn't been pres= sing (which is my way of agreeing with you: its imperfect, but it works alm= ost all the time today). Working well enough suggests we shouldn't '= ;gate' this change to a perfect solution.... Especially since we're= a bit short handed in the usb world after Hans' tragic passing.
<= div>=C2=A0
I would say it's a good idea to have something there in place t= o support these security keys (possibly also cameras, etc.), especially con= sidering the base OpenSSH now supports U2F devices.=C2=A0 It's probably= a good idea to have adduser / installer to have a defined "interactiv= e local user" groups (u2f, video, etc. come to mind) that users are ad= ded into by default to provide a reasonable out-of-box default too.

Totally agree here.=C2=A0
<= div>
Warner
--00000000000079eb54060e7385d7--