Open Bug 1734371 Opened 3 years ago Updated 5 days ago

Firefox snap can't load PKCS#11 modules on the host system

Categories

(Firefox Build System :: Third Party Packaging, defect, P2)

Product:
Firefox Build System
Component:
Third Party Packaging
Type:
defect

Tracking

(Not tracked)

Status:
REOPENED

People

(Reporter: olivier, Unassigned)

References

(Blocks 1 open bug)

Details

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:

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.

Blocks: snap

(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 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.

Component: Untriaged → Security: PSM
Product: Firefox → Core
Status: UNCONFIRMED → NEW
Ever confirmed: true

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.

Component: Security: PSM → Release Automation: Snap
Product: Core → Release Engineering
Version: Firefox 93 → unspecified

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

Severity: -- → S2
QA Contact: mtabara
See Also: → 1661935

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.

Component: Release Automation: Snap → Third Party Packaging
Product: Release Engineering → Firefox Build System
Version: unspecified → Trunk

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

Flags: needinfo?(olivier)

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).

Flags: needinfo?(olivier)

(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.

See Also: → https://launchpad.net/bugs/1843392
Priority: -- → P2

(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 ?

Flags: needinfo?(olivier)

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

Flags: needinfo?(olivier)

(In reply to Olivier Tilloy from comment #19)

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

Any news about this? Thanks

According to Launchpad, it's being worked on for a fix on Chromium, can we also work on Firefox ?

Flags: needinfo?(bandali)

Yes, the plan is to work on this for Firefox as well, but I'm not sure about the exact timeline.

Flags: needinfo?(bandali) → needinfo?(seb128)

It's on the Ubuntu Desktop team backlog and we hope to be able to work on it during this Ubuntu cycle

Flags: needinfo?(seb128)

Any news on this? It really is a blocker for using Ubuntu in a number of countries as it prevents interaction with government services.

Any news on this? It really is a blocker for using Ubuntu in a number of countries as it prevents interaction with government services."

You can always use firefox-esr. It does not use SNAP.

You can guarantee that it will always be so?

No. I am not a Ubuntu developer, Only OpenSC. But this problem has not been resolved for 2 years.

Also see https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1967632 and comment 8

(In reply to J Bedford from comment #24)

Any news on this? It really is a blocker for using Ubuntu in a number of countries as it prevents interaction with government services.

Maybe see this as a secuirty feature, not a bug :-)

Since this has been open for so long, I would like to point out that all these pkcs11 modules use a system PCSC-lite daemon. https://pcsclite.apdu.fr/ PCSC-lite provides locking and can use pol-kit to restrict access as needed. There should be only one PCSC daemon running for the system.

It would be a big limitation if the solution to this focuses entirely on pcsc-lite:

a) /var/run/pcscd/pcscd.comm is internal and varies between distributions and pcsc-lite versions. I.e. any pcsc-lite library embedded in the snap package is not guaranteed to be able to talk to the system pcscd

b) Remote desktop solutions such as ThinLinc or FreeRDP tend to override the pcsc library so that smart card access can be tunneled.

I would suggest having a more generic tunnel between the snap and the session the snap is running in. Either on the PC/SC layer, or on the PKCS#11 layer. The session side of that tunnel would then hopefully respect the session environment fully.

May I ask where we are with this problem?

I'm going to mark that as FIXED because the upstream bug https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1967632 is getting fixed with https://github.com/canonical/firefox-snap/pull/82 and https://github.com/canonical/firefox-snap/pull/83. There may still be some limitations but it depends on more specific modules and e.g. opensc-pkcs11.so should work.

Nathan can provide more details on the situation

Status: NEW → RESOLVED
Closed: 7 days ago
Flags: needinfo?(nathan.teodosio)
Resolution: --- → FIXED

What is currently possible in the nightly and beta builds is to load the opensc-pkcs11 module, by going to 'Settings > Cryptography modules > Load' and writing (NOT browsing for with the file picker)

/snap/firefox/current/usr/lib/x86_64-linux-gnu/opensc-pkcs11.so

The bug cannot be marked as fixed insofar as other modules are not loadable* and the "on the host system" part is not addressed.

*With a hack a host module might be loadable, the system needs to match Firefox' base (currently 22.04) and it depends on which libraries the module depends. The hack is namely

cp <module> $HOME/snap/firefox/common

and input that path in the text field of the module load window.

Status: RESOLVED → REOPENED
Flags: needinfo?(nathan.teodosio)
Resolution: FIXED → ---

Note also that there is a merge request[1] in progress for making the path of opensc-pkcs11 less awkward.

[1]https://github.com/canonical/firefox-snap/pull/83

You need to log in before you can comment on or make changes to this bug.