Firefox Flatpak 152.0.6 does not enumerate smart card tokens via p11-kit-proxy.so, but works with p11-kit-client.so
Categories
(Core :: Security: PSM, defect)
Tracking
()
People
(Reporter: kdg1955, Unassigned, NeedInfo)
References
(Blocks 1 open bug)
Details
Attachments
(2 files)
User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/150.0.0.0 Safari/537.36
Steps to reproduce:
Summary
Firefox Flatpak (org.mozilla.firefox) fails to detect Belgian eID smart card tokens when using the automatically loaded p11-kit module.
The same system works correctly with:
- Fedora's native Firefox package
- p11tool
- p11-kit
- OpenSC
- beidpkcs11
As a workaround, manually loading
/usr/lib/x86_64-linux-gnu/pkcs11/p11-kit-client.so
as a PKCS#11 module in Firefox immediately makes the smart card available.
Environment
Host:
- Fedora 44
- x86_64
Flatpak:
org.mozilla.firefox
Version: 152.0.6
Runtime: org.freedesktop.Platform 25.08
Branch: stable
Smart card
Belgian eID
Modules available on host:
- beidpkcs11
- opensc-pkcs11
Flatpak overrides
[Context]
sockets=pcsc;
filesystems=xdg-run/p11-kit/pkcs11;
[Environment]
P11_KIT_SERVER_ADDRESS=unix:path=/run/user/1000/p11-kit/pkcs11
Host verification
The host sees the card correctly.
p11tool --list-tokens:
- BELPIC (Belgium eID)
- BELPIC (OpenSC)
- System Trust
- Default Trust
p11-kit list-modules correctly lists:
- beid
- opensc
- p11-kit-trust
pkcs11-tool also detects the card.
Native Fedora Firefox can authenticate successfully using the Belgian eID.
Verification inside Flatpak
Inside the Firefox Flatpak sandbox:
p11tool --list-tokens
correctly lists
- BELPIC
- BELPIC
- System Trust
- Default Trust
Likewise,
p11-kit list-modules
correctly lists both Belgian eID tokens.
Therefore the p11-kit bridge is functioning inside the sandbox.
Problem
Firefox Security Devices automatically loads
/usr/lib/x86_64-linux-gnu/p11-kit-proxy.so
However, no smart card tokens are shown underneath this module.
The smart card reader LED never flashes when Firefox attempts authentication.
Authentication fails because Firefox never accesses the card.
Workaround
Manually add the following PKCS#11 module:
/usr/lib/x86_64-linux-gnu/pkcs11/p11-kit-client.so
After doing so:
- Firefox immediately enumerates the smart card slots.
- The reader LED flashes.
- Belgian eID authentication succeeds.
- CSAM login works normally.
This strongly suggests that NSS/Firefox fails to enumerate tokens through the automatically loaded p11-kit-proxy.so, while the p11-kit-client.so module works correctly.
Actual results:
Actual result
The automatically loaded p11-kit module exposes no smart card tokens until p11-kit-client.so is manually added.
Expected results:
Expected result
The automatically loaded p11-kit module should enumerate the same tokens that p11tool and p11-kit list-modules already see.
| Reporter | ||
Comment 1•2 months ago
|
||
Comment 2•2 months ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Security: Process Sandboxing' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
| Reporter | ||
Comment 3•2 months ago
|
||
I don't think "Core :: Security: Process Sandboxing" is the correct component.
The issue does not appear to be a general sandbox access problem. The same Firefox Flatpak installation can access the smart card successfully when using p11-kit-client.so.
The failure is specific to the p11-kit-proxy.so module: Firefox loads the proxy module, but no tokens are enumerated. This suggests an issue with the interaction between Firefox's PKCS#11 handling and the p11-kit proxy module inside the Flatpak environment, rather than a sandbox restriction.
A more appropriate component might be related to PKCS#11, security libraries, NSS, or Flatpak integration.
| Reporter | ||
Comment 4•2 months ago
|
||
Tomorrow, the most interesting tests will be:
Check whether another Flatpak app has the same problem
-
Chromium Flatpak would be a good comparison?
-
If possible, test p11-kit-proxy inside another Flatpak environment
That will tell us whether it is:
Firefox-specific, or
Flatpak/p11-kit-specific.
I will keep you posted.
| Reporter | ||
Comment 5•2 months ago
|
||
Unfortunately, I could not perform a meaningful comparison with another Flatpak application, as I was unable to reproduce the same PKCS#11 test scenario.
Additional testing shows that p11-kit-proxy.so works correctly on the Fedora host, both with pkcs11-tool and with NSS (modutil), where the BELPIC tokens are enumerated correctly.
The abnormal behavior is only observed when p11-kit-proxy.so is manually loaded in the Firefox Flatpak. In the same environment, manually loading p11-kit-client.so works correctly and the BELPIC tokens are available.
At this stage I cannot determine whether the root cause lies in the Firefox Flatpak packaging, the Flatpak runtime, or another integration layer.
Comment 6•2 months ago
|
||
The severity field is not set for this bug.
:jstutte, could you have a look please?
For more information, please visit BugBot documentation.
Comment 7•2 months ago
|
||
Any suggestions for a better fitting component? Thanks
| Reporter | ||
Comment 8•2 months ago
|
||
I would like to clarify one point from my previous comments.
The p11-kit-proxy.so module was not loaded automatically by Firefox. I had manually added it before starting my investigation, so it should not be interpreted as Firefox's default configuration.
The observed behaviour is:
Native Fedora Firefox works correctly with the Belgian eID.
Inside the Firefox Flatpak sandbox, p11tool --list-tokens and p11-kit list-modules both correctly enumerate the BELPIC tokens.
Manually loading p11-kit-proxy.so in Firefox does not expose any smart-card slots and authentication fails.
Manually loading p11-kit-client.so (/usr/lib/x86_64-linux-gnu/pkcs11/p11-kit-client.so) immediately exposes the smart-card slots, the reader becomes active, and Belgian eID authentication succeeds.
Based on these observations, I believe the issue is related to how Firefox/NSS interacts with these PKCS#11 modules rather than with the host configuration or the Flatpak sandbox itself.
Regarding the component, NSS :: Libraries seems to be the best fit, with Core :: Security: PSM as another possibility if the issue is determined to be in Firefox's integration with NSS.
Comment 9•1 month ago
|
||
This seems like a PSM issue, but if nothing else that seems like a good place to start looking for the right component. Redirecting needinfo.
Comment 10•1 month ago
|
||
Are you sure that p11-kit-proxy.so is meant to be used this way? Perhaps there's some additional configuration step necessary to make it work this way? I would start by asking the p11 kit folks if this is intended behavior: https://github.com/p11-glue/p11-kit/issues
| Reporter | ||
Comment 11•1 month ago
|
||
Yes. On the Fedora host, p11-kit-proxy.so is used this way and works correctly. The host p11-kit list-modules and p11tool --list-tokens output is already included in my previous comments.
The important difference is inside the Flatpak: p11-kit list-modules and p11tool --list-tokens both see the BELPIC tokens, but Firefox does not expose them when p11-kit-proxy.so is manually loaded.
In contrast, manually loading /usr/lib/x86_64-linux-gnu/pkcs11/p11-kit-client.so immediately exposes the smart-card slots and Belgian eID authentication succeeds.
So I agree it would be useful to confirm with the p11-kit developers whether p11-kit-proxy.so is intended to be loaded directly by NSS in this situation.
| Reporter | ||
Comment 12•1 month ago
|
||
Maybe useful information:
$> flatpak override --show org.mozilla.firefox
[Context]
sockets=pcsc;
filesystems=xdg-run/p11-kit/pkcs11;
[Session Bus Policy]
org.kde.plasma.browser.integration=talk
[Environment]
P11_KIT_SERVER_ADDRESS=unix:path=/run/user/1000/p11-kit/pkcs11
$>
Comment 13•1 month ago
|
||
Another question: did this work on an earlier version of Firefox? Can you use https://mozilla.github.io/mozregression/ to narrow down when it stopped working, if so?
| Reporter | ||
Comment 14•1 month ago
|
||
I haven't used mozregression before. My understanding is that it tests Mozilla's Firefox builds and is not a Flatpak Firefox regression tool.
Since the problem is specific to the Flathub/Flatpak build, I'm not sure that bisecting the regular Linux Firefox builds would identify when this particular problem was introduced.
The native Fedora Firefox works correctly, while the Flatpak Firefox does not work with "p11-kit-proxy.so" but does work when "/usr/lib/x86_64-linux-gnu/pkcs11/p11-kit-client.so" is manually loaded.
If you think a regression test is useful, could you advise whether you would like me to test older Flatpak Firefox versions specifically, rather than the regular Mozilla Linux builds?
| Reporter | ||
Comment 15•1 month ago
|
||
I don't actually know whether this is a regression. I only started investigating recently with the Flatpak version 152.0.6.
My personal impression is that it may never have worked with the Firefox Flatpak, but that's only a feeling — I have no earlier Flatpak version with which I can confirm that.
The native Fedora Firefox has worked with my Belgian eID, but I don't know whether the Flatpak version ever did.
If you think it would be useful, I can try older Flatpak Firefox versions to determine whether this has ever worked. I assume that would be more relevant than using mozregression with the regular Firefox Linux builds, since the problem appears specific to the Flatpak environment.
Comment 16•1 month ago
|
||
Oh, yeah, mozregression probably wouldn't be that much help here. You might try older flatpak versions if you can get them.
Comment 17•1 month ago
|
||
The severity field is not set for this bug.
:keeler, could you have a look please?
For more information, please visit BugBot documentation.
Comment 18•1 month ago
|
||
(In reply to Kristoffel from comment #0)
Firefox Security Devices automatically loads
/usr/lib/x86_64-linux-gnu/p11-kit-proxy.so
Do you know what is making Firefox load this module automatically? Do you have some sort of policy set up? (see about:policies)
If I'm understanding https://p11-glue.github.io/p11-glue/p11-kit/manual/sharing.html correctly, p11-kit-proxy loads other PKCS#11 modules (or, rather, it causes the process that loads it to load those modules). If I'm understanding Firefox's flatpak configuration (https://searchfox.org/firefox-main/rev/b0bc20aac45f7cb55b18adbf4d2313457659d140/python/mozbuild/mozbuild/repackaging/flatpak.py#244-269) correctly, Firefox doesn't necessarily have permission to load those library files. In other words, without giving Firefox permission to load (fairly) arbitrary library files, I just don't think this module is going to work at all (i.e. it's fairly incompatible with what I understand the general philosophy of flatpak to be).
Comment 19•1 month ago
|
||
I was told maybe Martin would have some experience here, at least with Flatpak?
Comment 20•1 month ago
|
||
Jan Horak is a flatpak expert here, ni him.
Comment 21•22 days ago
|
||
Redirect a needinfo that is pending on an inactive user to the triage owner.
:keeler, since the bug has recent activity, could you please find another way to get the information or close the bug as INCOMPLETE if it is not actionable?
For more information, please visit BugBot documentation.
Updated•21 days ago
|
Description
•