Allow PKCS#11 modules on Flatpak Chrome

[MarceloAlm]

These modifications enable the Flatpak Chrome environment to accept extensions that facilitate the loading of PKCS#11 modules into the internal NSS database.
Each extension can load a new module compatible with p11-kit (https://p11-glue.github.io/p11-glue/p11-kit/manual/), which will be loaded into the browser via p11-kit-proxy.so. When an extension is uninstalled, its module will be removed. This also allows users to install extensions without relying on host system libraries beyond PCSC.

To enable PKCS#11 modules to be loaded into the internal NSS database, the following adjustments to the application's loading process:

1. Establish a symbolic link from the modules files to /etc/pkcs11/modules. This allows the system's PKCS#11 infrastructure to discover and load the modules provided by the extensions.
2. Confirm that the NSS Database (NSSDB) is present within the Flatpak's sandbox environment. If it does not exist it will be created.
3. Incorporate the p11-kit-proxy.so library into the NSSDB's list of library modules. This step is crucial, as it enables NSS to utilize the p11-kit proxy for effectively loading and managing the PKCS#11 modules supplied the extensions.

A operational extension is avaliable at https://github.com/MarceloAlm/com.google.Chrome.libeToken.git. It enables the use of libeToken.so on Chrome, Safenet eToken.

[flathubbot]

Started test build 184971

[flathubbot]

Build 184971 successful
To test this build, install it from the testing repository:

flatpak install --user https://dl.flathub.org/build-repo/168205/com.google.Chrome.flatpakref

[flathubbot]

Started test build 185441

[flathubbot]

Build 185441 successful
To test this build, install it from the testing repository:

flatpak install --user https://dl.flathub.org/build-repo/168683/com.google.Chrome.flatpakref

[flathubbot]

Started test build 185446

[flathubbot]

Build 185446 successful
To test this build, install it from the testing repository:

flatpak install --user https://dl.flathub.org/build-repo/168688/com.google.Chrome.flatpakref

[flathubbot]

Started test build 186895

[flathubbot]

Build 186895 successful
To test this build, install it from the testing repository:

flatpak install --user https://dl.flathub.org/build-repo/170157/com.google.Chrome.flatpakref

[refi64]

I'm aware that support for this isn't great in the Flatpak world rn, but these extensions really feel like something that's pretty general and thus should be part of the base runtime itself instead, or at least something more generic? Rather than being tied to Chrome specifically.

[MarceloAlm]

Thank you for taking the time to look into this case.

At first I thought the same way and went to look up how the org.freedesktop team was working. The situation was much more complex than I imagined: the developers have been working for months on a portal to enable native Gnome/Plasma extensions, which is a feature with much greater demand. A PKI portal will not be on the roadmap any time soon.
The p11-kit libraries are already available on freedesktop and there must be applications implementing their own access; at least I saw that the Gnome runtime makes OpenSC available for its applications. Which could mean that removing these libraries could break existing packages.
Lastly, in my particular case, I need to use a proprietary code library, which I am not comfortable asking any flatpak maintainer to adopt in their SDKs.
I've been looking for a solution in the most generic way possible over the last few weeks, but few people actually report needing to access smartcards. In my case, I mostly need to do so through the browser.

I realized that the Flatpak team's major concerns about security and privacy don't allow for a very generic solution on this topic, as it runs the risk of exposing too many permissions to applications that don't need them.

Based on the workaround suggested by another user, it's possible to allow use without modifying Flatpak, but it requires a certain level of knowledge and violates a rule that shouldn't be done: the developer needs to be sure that their packages will behave the same way on any distribution.

I have no idea how much this feature is in demand in other browsers, but I believe that similar solutions can be proposed, which will lead to an evolution in this topic and, if all goes well, a definition of which model the community will adopt.

[MarceloAlm]

If you have a card compatible with Opensc, could you test the other extension: https://github.com/MarceloAlm/com.google.Chrome.opensc?
I bought a Feitian e2003 card, but I haven't been able to test it yet.