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

Bug#905373: marked as done (RFP: u2f-hidraw-policy -- Future-proof U2F device discovery)

Your message dated Wed, 12 Feb 2020 17:54:46 +0100
with message-id <20200212165446.ms2mc7mxtigfmghj@bogus>
and subject line Re: Bug #905373: Consider using u2f-hidraw-policy to discover U2F devices?
has caused the Debian Bug report #905373,
regarding RFP: u2f-hidraw-policy -- Future-proof U2F device discovery
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
905373: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905373
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message ---
Package: libu2f-udev
Version: 1.1.6-1

Hi,

libu2f-udev makes U2F devices accessible to users by matching hidraw devices against a list of vendor/product pairs. This means that any newly-released device will not work until libu2f-host is updated to add it to this list.

I noticed that Fedora takes a different approach: u2f-hidraw-policy[0] uses the discovery mechanism defined in the U2F HID spec[1] to determine whether a hidraw device supports U2F, and if so sets ID_U2F_TOKEN=1 and ID_SECURITY_TOKEN=1 on it. systemd ships a rule[2] which matches ID_SECURITY_TOKEN=1 and applies the "uaccess" tag, just as the rules shipped by libu2f-udev do. This has the nice property that newly-released devices work immediately, rather than needing an update to libu2f-host.

Is there some reason to prefer the libu2f-udev approach? While looking into making U2F tokens work out of the box on Endless OS, I put together some packaging for u2f-hidraw-policy[3]. It seems to work fine, and the approach seems cleaner than the list-of-devices approach. However, we generally prefer to follow Debian where possible, so I'm wondering if there's any interest in Debian adopting this mechanism!

Thanks,

– Will

[0] https://github.com/amluto/u2f-hidraw-policy/
[1] https://fidoalliance.org/specs/fido-u2f-v1.0-ps-20141009/fido-u2f-hid-protocol-ps-20141009.html#hid-report-descriptor-and-device-discovery
[2] https://salsa.debian.org/systemd-team/systemd/blob/master/src/login/70-uaccess.rules#L53-54
[3] https://salsa.debian.org/wjt-guest/u2f-hidraw-policy


--- End Message ---
--- Begin Message --- 
udev has support for autodetecting U2F/FIDO2 tokens since v244.
See https://github.com/systemd/systemd/issues/11996

As such, packaging u2f-hidraw-policy is not necessary anymore.


Best,

  nicoo


On Sat, Feb 23, 2019 at 05:38:02PM +0100, Nicolas Braud-Santoni wrote:
> Control: priority -1 wishlist
> Control: reassign -1 wnpp
> Control: retitle -1 RFP: u2f-hidraw-policy -- Future-proof U2F device discovery
> 
> Hi Will!
> 
> Sorry for only getting around to looking at this bug now  :(
> 
> 
> On Fri, Aug 03, 2018 at 05:48:44PM +0100, Will Thompson wrote:
> > libu2f-udev makes U2F devices accessible to users by matching hidraw
> > devices against a list of vendor/product pairs. This means that any
> > newly-released device will not work until libu2f-host is updated to add it
> > to this list.
> 
> Yes, this is correct.
> 
> 
> > I noticed that Fedora takes a different approach: u2f-hidraw-policy[0] uses
> > the discovery mechanism defined in the U2F HID spec[1] to determine whether
> > a hidraw device supports U2F.
> 
> This is interesting, I was unaware Fedora did it that way.
> 
> 
> > This has the nice property that newly-released devices work immediately,
> > rather than needing an update to libu2f-host.
> 
> Yes, that should achieve this.
> 
> 
> > Is there some reason to prefer the libu2f-udev approach?
> 
> I would be hesitant to change this within the release cycle for Buster, as we
> would need exposure to many different users (and their devices and
> configurations) to build confidence that this works correctly and introduces no
> regression.
> 
> In particular, if it relies purely on the uaccess mechanism, this will not
> work for Debian users who do not use systemd (or even just not pam-systemd).
> This is fixable, though.
> 
> Moreover, this is C code, running as root and unconfined, every time a USB
> device is plugged in, so I'd rather take the time to audit it before shipping it
> to users.  :)
> 
> (Re: unconfined, it would likely be worth writing a restrictive AppArmor policy
>  and submit it back upstream.)
> 
> 
> > The approach seems cleaner than the list-of-devices approach.
> 
> At least, it should be more future-proof  :)
> 
> 
> > I'm wondering if there's any interest in Debian adopting this mechanism!
> 
> I'd be interested in at least trying it out.
> 
> If you would like, I can help getting your package into shape, and into
> experimental.
> 
> Once it's there, the next logical staps would be to:
> - get contributors to test it (feedback from EndlessOS would be useful, but
>   also getting people to use it on Debian) ;
> - assuage security concerns, by reviewing the C code, making it drop privileges,
>   and adding an AppArmor profile;
> - get it into unstable;
> - eventually update the dependency of task-desktop (and other packages) to use
>   u2f-hidraw-policy (or at least u2f-hidraw-policy | libu2f-udev).
> 
> That's all things I can help with (I'm even a tasksel uploader, so I can deal with
> that part too), but I've been struggling with health issues so I might not be the
> most responsive.
> 
> Please feel free to poke me, either on the bug, or over IRC (nicoo on freenode
> or OFTC), if I'm not replying.
> 
> 
> @Simon, Klas: Do you have any thoughts on this, or experience with the
>               reliability of U2F autodetection?
> 
> 
> Best,
> 
>   nicoo

Attachment: signature.asc
Description: PGP signature


--- End Message ---
Reply to: