From nobody Mon Jan 8 18:43:56 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 4T82yy1ZyMz56Pw4 for ; Mon, 8 Jan 2024 18:44:10 +0000 (UTC) (envelope-from delphij@gmail.com) Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) (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 4T82yx6hnkz4DcG; Mon, 8 Jan 2024 18:44:09 +0000 (UTC) (envelope-from delphij@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-lf1-x12c.google.com with SMTP id 2adb3069b0e04-50e67e37661so2529577e87.0; Mon, 08 Jan 2024 10:44:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704739448; x=1705344248; 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=7JG/71P2fxyQFxoZhk617xf+Y21cyWPgGzaKvylEI5s=; b=BliG63jwDf/wZngXWaUZCmka4Kju/p2tdUGZztBDwq3nkb0iCUzmnV0Nz7awIiEmEg lEGZAU9WZrKb3Eq+9/mqHl1whHEpW++QAZxpAo02zmQHghpJS5v9kjHQzC8yVYrsB9k0 QWU/Woc+qf5FBufqQ7Mmnbkc47gMpe1fyf6xcvhTJL5vIvB0i8GLkU+X2Cf3ikfnuzkI SX4FmHMVpkk0MuyE1IXmlZAouruOHBOUZaKET0eUtPUstkTCwnaLTROKn1WeHTGRBFCc 3jL3CU1kOTE6718dOhGtR90wP11ddpDccButqzWnFrB36PIAJriUAge8AYUWhwF8Q0Ma yRng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704739448; x=1705344248; 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=7JG/71P2fxyQFxoZhk617xf+Y21cyWPgGzaKvylEI5s=; b=CBv2JpaVx3SQXbd1pRYv6p6e2qj3qlAEEcRzmPvQa2pucDYqBft7txVNbi5YnE7I0C HCoF8hLRmWelJ0h6G1YyetjirYPDf37fvHYukwVcLm5/XLuKY3nHpxrPyF4XTZ338Wfk 5MyqzTJ5OaG2u/pcj25ZC8G/pzSAcDoxVpKfrCgZMaNP3zEhkEuF+FMp+lposPRdEDvm UTFK2v9bepXygjdncB2OLGp5sw8DXhRQRe3tbe2Jr7RaOSp4gyo+CE8snkW9vDI3v53N 3tYzkC/xKnvwrC3DzVlQhoGLTVbt1t0DeO/lvJMwvZfDfO5M4XgPTuitzMKOhBhfetvy 8qXg== X-Gm-Message-State: AOJu0YxTxsUslpYGvClVIRGjKzBD8fgUZ0DyA0xA2qYhA9hAIx2scU98 cv3J65c6ZtOC9/CUtvF4ClQLaNHQtZU/gADmwASwHR1v X-Google-Smtp-Source: AGHT+IH89ogLxgxyQ9UmfkmVQGy/oaF7xvpSkfTrN3Pq//YyQVk3162ZrnYYdIR2a5shH65OOQ1hDJcBbmFZmHRYJLQ= X-Received: by 2002:a05:6512:3c81:b0:50e:7555:ddf4 with SMTP id h1-20020a0565123c8100b0050e7555ddf4mr2176428lfv.20.1704739447715; Mon, 08 Jan 2024 10:44:07 -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: <20240109013058.22807f3816603829316cef4c@dec.sakura.ne.jp> In-Reply-To: From: Xin LI Date: Mon, 8 Jan 2024 10:43:56 -0800 Message-ID: Subject: Re: Move u2f-devd into base? To: Warner Losh Cc: Kyle Evans , freebsd-current@freebsd.org Content-Type: multipart/alternative; boundary="000000000000373e64060e739558" X-Rspamd-Queue-Id: 4T82yx6hnkz4DcG 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] --000000000000373e64060e739558 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jan 8, 2024 at 10:37=E2=80=AFAM Warner Losh wrote: > > > On Mon, Jan 8, 2024 at 9:35=E2=80=AFAM Kyle Evans wr= ote: > >> On 1/8/24 10:30, Tomoaki AOKI wrote: >> > On Mon, 8 Jan 2024 08:18:38 -0700 >> > Warner Losh wrote: >> > >> >> On Mon, Jan 8, 2024, 7:55=E3=80=93AM 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.. >> >> >> >> Warner >> >> >> >> -- >> >>> Christian "naddy" Weisgerber >> naddy@mips.inka.de >> > >> > It's devd.conf materials. It actually is security/usf-devd/files >> > u2f.conf and its contents is sets of notify 100 { match "vendor" ... >> > match "product" ... action "chgrpy u2f ..." };. >> > Some hase more items in it, though. >> > >> > So it should be in ports to adapt for latest products more quickly tha= n >> > in base, I think. >> > >> >> I don't see any obvious reason that we can't compromise and have a >> baseline of products in base and just use the port for new products not >> yet known to base. These vendors presumably aren't going to quickly >> repurpose some PID for a non-u2f thing, much less in a way that we care >> about. >> > > Yea, I just wonder why it has to be devd.conf, and not devfs.conf. What a= re > we missing from that to make this doable generically? If we want it safe, > we > may need some additional work around the whole ugen thing it uses. > I think it's probably because of the lack of device ID matching capability in devfs.conf (or in other words, there may be _some_ reason that I am not aware of, to not expose all USB HID devices to desktop users; devd.conf gives us the ability to selectively expose them based on what they claim themselves to be, while with devfs.conf we can only say "expose HID devices" vs "expose these allowlisted devices"). Cheers, --000000000000373e64060e739558 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Jan 8, 2024 at 10:37=E2=80= =AFAM Warner Losh <imp@bsdimp.com&= gt; wrote:


On Mon, Jan 8, 2024 at 9:35=E2=80=AFAM Kyl= e Evans <kevans@= freebsd.org> wrote:
On 1/8/24 10:30, Tomoaki AOKI wrote:
> On Mon, 8 Jan 2024 08:18:38 -0700
> Warner Losh <im= p@bsdimp.com> wrote:
>
>> On Mon, Jan 8, 2024, 7:55=E3=80=93AM Christian Weisgerber <naddy@mips.inka.de&= gt;
>> 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 nod= es)
>>> 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 devfs.conf no? Otherwise it's a race.= .
>>
>> Warner
>>
>> --
>>> Christian "naddy" Weisgerber=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 naddy@mips.inka.de
>
> It's devd.conf materials. It actually is security/usf-devd/files > u2f.conf and its contents is sets of notify 100 { match "vendor&q= uot; ...
> match "product" ... action "chgrpy u2f ..." };. > Some hase more items in it, though.
>
> So it should be in ports to adapt for latest products more quickly tha= n
> in base, I think.
>

I don't see any obvious reason that we can't compromise and have a =
baseline of products in base and just use the port for new products not yet known to base.=C2=A0 These vendors presumably aren't going to quick= ly
repurpose some PID for a non-u2f thing, much less in a way that we care about.

Yea, I just wonder why it has to= be devd.conf, and not devfs.conf. What are
we missing from that = to make this doable generically? If we want it safe, we
may need = some additional work around the whole ugen thing it uses.
=

I think it's probably because of the lack = of device ID matching capability in devfs.conf (or in other words, there ma= y be _some_ reason that I am not aware of, to not expose all USB HID device= s to desktop users; devd.conf gives us the ability to selectively expose th= em based on what they claim themselves to be, while with devfs.conf we can = only say "expose HID devices" vs "expose these allowlisted d= evices").

Cheers,

--000000000000373e64060e739558--