Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

What USB vendor/ID is WearAuthn? #17

Open
MrConorAE opened this issue May 9, 2022 · 6 comments
Open

What USB vendor/ID is WearAuthn? #17

MrConorAE opened this issue May 9, 2022 · 6 comments

Comments

@MrConorAE
Copy link

Hi!
I'm going to open a request for Snap to add WearAuthn as a supported key for the u2f-devices plug, to allow keys to work in snapped apps like Firefox.
Problem is, WearAuthn doesn't show up in lsusb, so I can't determine what ID to submit.

Here's my output of lsusb (it's the same before and after attaching):

Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 005: ID 138a:0097 Validity Sensors, Inc. 
Bus 001 Device 004: ID 13d3:5682 IMC Networks SunplusIT Integrated Camera
Bus 001 Device 003: ID 8087:0a2b Intel Corp. Bluetooth wireless interface
Bus 001 Device 002: ID 046d:c52f Logitech, Inc. Unifying Receiver
Bus 001 Device 006: ID 056a:50b6 Wacom Co., Ltd Pen and multitouch sensor
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Is it 8087:0a2b Intel Corp. Bluetooth wireless interface, or something else?

Thanks,
MrConorAE

@Thesola10
Copy link

Devices paired via Bluetooth don't open a USB bus. They do, however, open a raw HID device, so you may want to look into a udev rule.

@fmeum
Copy link
Owner

fmeum commented May 14, 2022

I'm not completely sure how the snap permissions work. It's possible you would need both a udev rule and allowlist the Bluetooth adapter. But as @Thesola10 said, I would try adding a udev rule first.

@Thesola10
Copy link

Allowing access to the Bluetooth adapter through USB would be pointless. The Linux Bluetooth stack has a single daemon take over the adapter and communicate with udev to register devices, so it would be a bit like allowlisting a PCIe controller -- that's just not how sandboxed apps are supposed to work.

@MrConorAE
Copy link
Author

As far as I understand it, all the snap permission system needs is a way of identifying the key - and for most of them, that's through a specific vendor/ID combination.

So should the rule for the snap permission be for the Bluetooth adapter or the watch itself?

@MrConorAE
Copy link
Author

For reference, if it helps, the list of properties for the u2f-devices allow list is at https://github.com/snapcore/snapd/blob/master/interfaces/builtin/u2f_devices.go#L44

@fmeum
Copy link
Owner

fmeum commented May 14, 2022

I think that this approach is problematic since vendor and product ID depend on the watch model and can't be set by WearAuthn. Thus, all WearOS watches would have to be allowlisted individually. A more sustainable approach I implemented in systemd: systemd/systemd@d45ee2f
Could something similar be viable for snap? It would remove the need to maintain am allowlist.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants