Comment 9 for bug 1843392

Whoops, sorry, I didn't mean to do that :)

Basically though, this is causing issues for users in, e.g., Belgium, who want to do their tax declaration using Ubuntu and their electronic ID card. We are currently guiding users to use a non-snap browser (see https://eid.belgium.be/en/faq/why-it-not-possible-use-eid-software-snap-andor-flatpak#7636), and that's just sad.

Comment #1 mentions a proposal to possibly resolve this. Since it explicitly asks for feedback, here is some (belated) feedback:

First, PKCS#11 is about more than just smartcards. While allowing access to the pcscd socket from within the confined environment might allow some PKCS#11 modules to work, using this as a solution assumes all PKCS#11 modules use PC/SC as a backend API, and that's a wild assumption which is probably not true for everything. PKCS#11 is a generic cryptographic plug-in API, which allows hardware crypto modules of any kind (e.g., USB tokens, Networked HSMs, PCI(e) crypto accelerator boards, TPM modules, etc etc) to be plugged into anything. libnss uses it mostly for smartcards, and all browsers on Linux do so as well, but it can also be used by libreoffice and evolution to sign documents, it is extensively used by OpenDNSSEC for its crypto operations (going so far as providing a "SoftHSM" pkcs#11 module and not having native crypto), OpenSSH has had PKCS#11 code for a while to read and use certificates, and there are ways to hook PKCS#11 up to OpenSSL allowing for a large number of other applications to use HSMs.

PKCS#11 modules could possibly access the hardware that they're written for using PC/SC (which this proposal could possibly work for, as long as the libpcsclite.so inside the snap and the pcscd outside the snap are sufficiently in sync), but this would not help PKCS#11 modules for USB tokens, TPM modules, PCI crypto accelerators, or possibly networked systems (depending on how the host application is confined).

Apart from hardware, PKCS#11 modules may sometimes need to do other things as well. E.g., the Belgian eID middleware needs to occasionally show certain messages to the user, for which it uses the GnuPG pinentry framework to show a dialog box that integrates with the user's UI. Unless this is explicitly allowed by the snap, this won't work. There might be other similar issues with other PKCS#11 modules, which means that running them in a confined environment might just not work.

So while this may be a solution for some PKCS#11 modules, it will not be a solution for all.

Additionally, the PKCS#11 modules need to be installed and registered in host applications. For NSS-based applications, this means they need to be installed using "modutil". Chrome doesn't even *have* any UI to install PKCS#11 modules; Firefox does, but it's so basic and confusing to users that I developed a "browser.pkcs11" add-on API for Firefox to allow modules to be registered using an add-on. These work with native manifests (intentionally similar to native messaging manifests) and expect the PKCS#11 module to be in the location as specified by the manifest. Libreoffice just gave up and looks for a Firefox, Thunderbird, or Chromium configuration directory and reuses that. As such, just allowing access to a PKCS#11 module is not going to be sufficient if the user has no easy way to register the PKCS#11 modules.

An alternate method (that I suggested at https://github.com/flatpak/xdg-desktop-portal/issues/662) is to use p11-kit-proxy to provide a bridge between the confined system and PKCS#11 modules. p11-kit-proxy could then communicate with the unconfined world using a dbus service. A proof-of-concept implementation of this exists (see the github link), and the only reason why it's not in common use right now is that p11-kit-proxy is not commonly added to, and enabled in, snaps.