[snap] smart card reader no longer works

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:93.0) Gecko/20100101 Firefox/93.0

Steps to reproduce:

This is a snap-specific issue. It was previously reported in various places:
  - https://forum.snapcraft.io/t/cant-load-security-device-in-firefox-snap/12471
  - https://forum.snapcraft.io/t/confined-browser-snaps-cant-use-system-libraries-pkcs11-and-native-host-messaging-what-do-we-do/11828
  - https://forum.snapcraft.io/t/access-external-lib-to-use-usb-token-in-firefox/13959
  - https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1843392

Snapd's strict confinement makes it impossible for the firefox snap to load PKCS#11 security devices from `about:preferences#privacy` ("Security Devices" button in the "Security" section), because it denies access to `/usr/lib/pkcs11` and to `/var/run/pcscd/pcscd.comm`.

(from https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1843392/comments/1)

The proposed approach to solve this that was discussed with the Ubuntu security team is:
 - stage common PKCS modules in the snap
 - add a layout for `/usr/lib/pkcs11` pointing to a writeable area of the snap (e.g. `$SNAP_USER_DATA/.local/lib`)
 - on first run, copy the common PKCS modules to that writeable area
 - document that custom modules (and their dependencies?) should be manually copied to that directory
 - create a new interface (not auto-connected, that's okay) for access to `/var/run/pcscd/pcscd.comm`

I'm not familiar with how smart card readers work though, so feedback and suggestions are welcome.

The [Bugbug](https://github.com/mozilla/bugbug/) bot thinks this bug should belong to the 'Core::Security: PSM' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Seems like it would be easier to allow access to `/usr/lib/pkcs11` and `/var/run/pcscd/pcscd.comm`, but I don't know what options snap has for that.

This seems similar: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Native_messaging
IIUC Firefox and Chrome (as important as systemd) need to be able to start binaries that are defined in certain json files. Those binaries are installed by non-snap packages or scripts and need to run as the regular user. Such a binary can be used to control other applications or to talk to hardware or to flash firmware.

https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Native_manifests
> There are three different types of native manifest:
> * Native messaging manifests
> * Managed storage manifests
> * PKCS #11 manifests

> Linux
> For global visibility, store the manifest in either:
> /usr/lib/mozilla/native-messaging-hosts/<name>.json
> /usr/lib/mozilla/managed-storage/<name>.json
> /usr/lib/mozilla/pkcs11-modules/<name>.json
or:
> /usr/lib64/mozilla/native-messaging-hosts/<name>.json
> /usr/lib64/mozilla/managed-storage/<name>.json
> /usr/lib64/mozilla/pkcs11-modules/<name>.json
>
> For per-user visibility, store the manifest in:
> ~/.mozilla/native-messaging-hosts/<name>.json
> ~/.mozilla/managed-storage/<name>.json
> ~/.mozilla/pkcs11-modules/<name>.json

Right, so for the pkcs11 browser extension API to work, we will also need to grant the firefox snap read access to `/usr/lib{,64}/mozilla/{native-messaging-hosts,managed-storage,pkcs11-modules}`. Thanks @Darkspirit for this additional piece of information.

For future reference, manual installation and provisioning through the API of PKCS#11 modules is documented here: https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/PKCS11/Module_Installation.

Not only that, the snap would need to parse these json files and allow Firefox&Chrome to start the binary defined in "path" with full access to the system as a regular user. The binary needs to be able to do what it wants. (It's somewhat like allowing Firefox to start pre-defined systemd services.)
If that doesn't happen, users might switch to a potentionally less secure alternative to native messaging, for example, running a local webserver accessible by every website and possibly without proper authentication which then executes commands.

Another option could be to create a dbus service to enumerate and/or use PKCS#11 modules that are registered into p11-kit. This would allow any PKCS#11 module to work, not just those that use pcsclite behind the scenes.

That might be a bit more work (the full p11-kit and PKCS#11 API would need to be mapped onto dbus), but it seems to me to be less of a layering violation?

As pointed out by several persons in various places, this problem (PKCS#11 modules) and the issue with native messaging share a common denominator: native manifests (https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Native_manifests).

> S2 (Serious) Major functionality/product severely impaired and a satisfactory workaround does not exist

See https://github.com/flatpak/xdg-desktop-portal/issues/662.

When apparmor is also used, the PKCS11 module also needs "M" (file_mmap) but this is a first step
I believe the idea of copying the files to a the "doc" is not needed, if "M" and "R" access were available to
/usr/lib/x86_64-linux-gnu/pkcs11 (or equivalent on other systems.) This is where the p11-kit-client.so module (and others) resides.

As an OpenSC developer, this problem as been reported on https://github.com/OpenSC/OpenSC/issues/2552
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1967632.

Let me know if there is anything I can do to assist is getting smart cards working again with snap.

The linked https://github.com/flatpak/xdg-desktop-portal/issues/662 has had no activity, can we help in some way?

> The linked https://github.com/flatpak/xdg-desktop-portal/issues/662 has had no activity, can we help in some way?

Maybe. The problem appears to be with the packaging of PKCS11 modules when using SNAP as noted in: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1967632/comments/8

The Debian version of FireFox without SNAP works fine, but Ubuntu in 22.04 packaged FireFox as a SNAP application does not.

I would hope that Mozilla developers could could work with Ubuntu SNAP developers to resolve the issue. Either to get it to work with SNAP or talk Ubuntu in to not making the default FireFox be the SNAP version.
As best as I can tell every PKCS11 module would have to be configured for SNAP and that does not look easy.

For the proposal of a PKCS#11 portal to stand a reasonable chance of being accepted and implemented, I think we need to wait for the WebExtensions portal to prove itself (this is in a fairly advanced state, the portal is already available in Ubuntu 22.04, and integration in Firefox is complete and I'm hoping it'll land soon).

(In reply to deengert from comment #13)
> > The linked https://github.com/flatpak/xdg-desktop-portal/issues/662 has had no activity, can we help in some way?
>
> Maybe. The problem appears to be with the packaging of PKCS11 modules when using SNAP as noted in: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1967632/comments/8

Thanks, it's detailed, having a quick look it seems like it's already properly documented as distro-level packaging issue then ?

Yes it looks like distro-level packaging issue. But to end user it looks like a regression of FireFox and/or smartcard support which is important to only a small percentage of FireFox users. So distro maybe slow to do anything about it. A few words to the distro from Mozilla might help get this fixed.

(In reply to Olivier Tilloy from comment #1)
> (from https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1843392/comments/1)
>
> The proposed approach to solve this that was discussed with the Ubuntu security team is:
> - stage common PKCS modules in the snap
> - add a layout for `/usr/lib/pkcs11` pointing to a writeable area of the snap (e.g. `$SNAP_USER_DATA/.local/lib`)
> - on first run, copy the common PKCS modules to that writeable area
> - document that custom modules (and their dependencies?) should be manually copied to that directory
> - create a new interface (not auto-connected, that's okay) for access to `/var/run/pcscd/pcscd.comm`
>
> I'm not familiar with how smart card readers work though, so feedback and suggestions are welcome.

Why can't the snap package be configured to just let access to /var/run/pcscd/pcscd.comm?
The PKCS#11 libs are normally platform/distribution dependent, so you can't just include it in a snap package hoping this will works anywhere.
Dependencies are more platform dependent, 1 over all: libpcsclite.so.1 library shall match the protocol version of his server, you can't just bring it in the snap packages and hope it works.
It looks like Snap is by now very immature technology to run the default version of FF on Ubuntu.

(In reply to Olivier Tilloy from comment #1)
> (from https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1843392/comments/1)
>
> The proposed approach to solve this that was discussed with the Ubuntu security team is:
> - stage common PKCS modules in the snap
> - add a layout for `/usr/lib/pkcs11` pointing to a writeable area of the snap (e.g. `$SNAP_USER_DATA/.local/lib`)
> - on first run, copy the common PKCS modules to that writeable area
> - document that custom modules (and their dependencies?) should be manually copied to that directory
> - create a new interface (not auto-connected, that's okay) for access to `/var/run/pcscd/pcscd.comm`
>
> I'm not familiar with how smart card readers work though, so feedback and suggestions are welcome.

Is this still a plan ? Is anybody on Canonical side working on that ?

Not currently, but it is on my short-term to-do list.