Add USB device access portal

[hadess]

TBD

[matthiasclasen]

the way forward for these is for some application that needs these devices to step up and get a design for a portal, propose a portal api, and implement it. I'm happy to assist with these steps, but I'm unlikely to produce more portals all by myself without concrete involvement from api consumers.

[hadess]

the way forward for these is for some application that needs these devices to step up and get a design for a portal, propose a portal api, and implement it. I'm happy to assist with these steps, but I'm unlikely to produce more portals all by myself without concrete involvement from api consumers.

I'm getting the process started now.

[hadess]

Prior art

• iOS "External Accessory" framework:
  https://developer.apple.com/documentation/externalaccessory
  https://developer.apple.com/library/archive/featuredarticles/ExternalAccessoryPT/Introduction/Introduction.html#//apple_ref/doc/uid/TP40009502

• Android USB host overview:
  https://developer.android.com/guide/topics/connectivity/usb/host

• USB device access for Chrome Apps:
  https://developers.chrome.com/apps/app_usb

On iOS, a device will declare which protocols it speaks (less "USB mass-storage" and more com.Hwmanufacturer.MassStorage), and apps will list which protocols they support. Whether apps are allowed to enumerate those devices is gated through the App Store, whether an app can access a specific device is done at the OS level ("App blah wants to access foo").

On Android, the process is similar. The application must declare which devices (USB vendor and product IDs), or which class/subclass (all headsets, all mass-storage devices) ahead of time, in its manifest. Enumeration is allowed within those boundaries, authorisation to access is then requested. It seems that Android doesn't handle only allowing certain endpoints to be accessed.

Chrome OS/Chrome Apps works similarly to Android.

Draft design

• supported devices get listed in the Flatpak manifest, or in a separate file shipped in the Flatpak. We need to be able to access it from outside the sandbox to show it somewhere like the Privacy settings panel, or GNOME Software. This avoids applications being able to fingerprint users and devices.

• add a portal that uses that device list, and filters out the rest of the devices for enumeration. This doesn't require authentication.

• add a portal to open a particular device. If the enumeration is filtered on interface class, disallow claiming any interface but the one that was filtered on. This would trigger an authorisation dialogue. Ideally, the portal would be able to open devices without needing them to be accessible by the user itself. Do we want to make this a polkit authorisation instead of a Portal-level one? Do we also want to allow kernel drivers to be detached?

• modify libusb to use that portal when run inside a flatpak

• add a per-app toggle to allow/disallow USB access, which would just make libusb say that there's no supported devices.

[alexlarsson]

For listing the usb devices supported, maybe we can use the --add-policy=SUBSYSTEM.KEY=VALUE generic flatpak permissions. These are copied into the metadata file and will be accessible in /.flatpak-info for the running instance.

However, i'm not sure how this prohibits fingerprinting? Surely you can just list a shitload of devices? Would make the finger-printer more obvious though...

For the per-app permissions, we can store those in the permissions store.

Other than that, this sounds like a plan to me, but the devil is gonna be in the details.

[hadess]

For listing the usb devices supported, maybe we can use the --add-policy=SUBSYSTEM.KEY=VALUE generic flatpak permissions. These are copied into the metadata file and will be accessible in /.flatpak-info for the running instance.

Ideally, this would be imported into the manifest by flatpak-builder, so that we can have the applications programmatically list those identifiers during the build. A static list inside the manifest is probably fine if you support a single type of device, or just a few devices, but that list could get long (in the tens) pretty easily.

However, i'm not sure how this prohibits fingerprinting? Surely you can just list a shitload of devices? Would make the finger-printer more obvious though...

You'd need to list about 130k items if you wanted to list every possible VID:PID combinations. The user or the repository owner would surely notice.

For the per-app permissions, we can store those in the permissions store.

OK.

Other than that, this sounds like a plan to me, but the devil is gonna be in the details.

As always :)

[hadess]

You'd need to list about 130k items

Sorry, it's about 4 billion :)

[bl33pbl0p]

Slightly offtopic but with the potential of simplifying the implementation, recently device namespaces support made it into the kernel (so a privileged process with CAP_SYS_ADMIN can tag uevents and send to the correct network namespace owned by a user namespace) and then the device manager running inside that or just a little process listening for those could act accordingly. I don't know if this is useful for the portals implementation but I guess this might be interesting for, say, systemd, which could grow support to expose this to other users as some API that flatpak could benefit from. Ignore if this is irrelevant (perhaps this could be something flatpak developers can discuss with Lennart and work something out that is useful for everyone now that newer kernels support it).

[hfiguiere]

As an example, libgphoto2 has a set of udev rules and a script to properly setup permission on the devices with udev (on Fedora it is these two files):

/usr/lib/udev/check-ptp-camera
/usr/lib/udev/rules.d/40-libgphoto2.rules

Maybe we could provide a similar mechanism for the portal to determine which devices should be granted permission.
With libgphoto2 the library is in the flatpak so this generated list could be used for the policy,

[hadess]

Maybe we could provide a similar mechanism for the portal to determine which devices should be granted permission.
With libgphoto2 the library is in the flatpak so this generated list could be used for the policy,

Sorry, I don't understand to what that "mechanism" would be similar. udev permissions aren't usable or reliable for sandboxed applications, as applications can't rely on the host side having updated libraries and data files to give them access to devices, or the necessary updated libraries to detect devices at runtime (especially if that requires talking to the devices).

[hadess]

Slightly offtopic but with the potential of simplifying the implementation, recently device namespaces support made it into the kernel (so a privileged process with CAP_SYS_ADMIN can tag uevents and send to the correct network namespace owned by a user namespace) and then the device manager running inside that or just a little process listening for those could act accordingly.

udev events are not usable inside a sandbox as the kernel/user-space API and ABI is purposefully not designed to be forward or backwards compatible. Even if it were, filtering is done on the user-space side, so would leak information to the sandboxed application, and that would still leave the problem of device access (rather than device discovery).

[rugk]

Strongly related to supporting U2F/WebAuthn via USB, see: #989