Cannot read/write to usb device [libusb][hidapi]

Bug #1598266 reported by Szczepan
18
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Snappy
Fix Released
Undecided
Unassigned

Bug Description

Hi!

I am trying to use Nitrokey Stick with snapped Nitrokey App (https://github.com/Nitrokey/nitrokey-app).
Snapcraft yaml repo: https://github.com/Nitrokey/nitrokey-app.snappy
App store adress: https://myapps.developer.ubuntu.com/dev/click-apps/5313/rev/2/

I believe this is different than #1591839 Can't read/write to USB devices

App is working correctly in --devmode. However in strict mode I am blocked from read/write to usb and unable to even recognize that device is connected. Application is using hidapi (libusb).
I am attaching log from apparmor, taken with:
/snap/bin/snappy-debug.security scanlog nitrokey-app

Revision history for this message
Szczepan (szszszsz) wrote :
Revision history for this message
Szczepan (szszszsz) wrote :
description: updated
Szczepan (szszszsz)
description: updated
Revision history for this message
Zygmunt Krynicki (zyga) wrote :

This looks like raw USB access is required.

From the source code referenced above it seems that the following USB vid/pid pairs are used.

#define VID_STICK_OTP 0x20A0
#define PID_STICK_OTP 0x4108

#define VID_STICK_20 0x20A0
#define PID_STICK_20 0x4109 // MSD + CCID + HID production id

#define VID_STICK_20_UPDATE_MODE 0x03EB
#define PID_STICK_20_UPDATE_MODE 0x2FF1

I think we'd have to craft a new interface that would somehow let those specific devices be allowed but I'd have to discuss with the team on how this could be done. I think it would require the ongoing hook support to land before we could attempt this (so that we could interrogate udev and find the appropriate devices).

As another approach we could use the udev security backend to inject an udev rule that makes those devices accessible.

Changed in snappy:
status: New → Triaged
Revision history for this message
Jamie Strandboge (jdstrand) wrote :

This is precisely what the Udev backend is for but the trick is correctly enumerate those devices so that they are tagged appropriately for the Udev backend to use and to correctly enumerate the /sys and /run/udev files based on the udev queries so the apparmor policy be updated in a fine-grained manner. I'm not sure a new interface specific for these devices is what we want here-- we would end up with as many interfaces as there are devices.

This is getting at one of the reasons why interfaces were created: to replace 15.04's hw-assign methodology, but AFAIK the USB cases have not been fully explored. In other words, I agree this needs more discussion.

Revision history for this message
Szczepan (szszszsz) wrote :

Hi!
Has something changed in the topic of USB devices access recently?

Revision history for this message
Alistair Buxton (a-j-buxton) wrote :

Here is the list of hardware supported by sigrok:

https://sigrok.org/wiki/Supported_hardware

Every one has a different ID (some more than one due to firmware loading) and there are many different protocols. Even listing all the VID/PID combinations would be impractical.

There is also the case that you want to do the equivalent of "lsusb -v" inside a snap, which requires full access to every USB device.

Leo Arias (elopio)
tags: added: snapd-interface
removed: snapd-interfaces
Revision history for this message
Jamie Strandboge (jdstrand) wrote :

Marking this bug as fix released since the raw-usb interface should allow access to all USB devices. Hotplugged devices and per device assignment is still planned. Please see https://github.com/snapcore/snapd/wiki/Interfaces for details.

Changed in snappy:
status: Triaged → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.