search

ValveSoftware / steam-runtime

A runtime environment for Steam applications
Other
1.18k stars 86 forks source link

steamwebhelper crashloops due to reading /run/current-system/sw/lib/libbeidpkcs11.so from ~/.pki/nssdb/pkcs11.txt on NixOS 24.05.20240425.7bb2ccd (Uakari) x86_64 #667

Closed MarkRijckenberg closed 5 months ago

MarkRijckenberg commented 5 months ago

Your system information

Please describe your issue in as much detail as possible:

See https://github.com/NixOS/nixpkgs/issues/298662

Steps for reproducing this issue:

See https://github.com/NixOS/nixpkgs/issues/298662

Proposed solution:

Proposed solution to avoid conflict between "eid-nssdb add" command (part of eid-mw package in NixOS) and steam client: Apparently, steam-runtime-heavy.tar.xz and steam-runtime-sniper.tar.xz contain libnss3 (network security service libraries) Replace libnss3 library with openssl so that the steam client does not support PKCS security modules anymore. Does the steam client really need to support PKCS? If yes, why exactly?

Workaround for issue:

Launching steam via flatpak circumvents this crashloop issue.

TTimo commented 5 months ago

this should probably in in the steam-runtime tracker?

smcv commented 5 months ago

This is the same issue as https://github.com/ValveSoftware/steam-for-linux/issues/10649, which has some more information, including crash dumps.

Apparently, steam-runtime-heavy.tar.xz and steam-runtime-sniper.tar.xz contain libnss3 (network security service libraries)

Yes. libnss3 is a SSL/TLS implementation originally from Mozilla, and is used by several larger components. The one that is relevant here is that the Steam user interface steamwebhelper is based on a generic web engine, CEF, which is eventually derived from Chromium.

We cannot remove libnss3 from sniper, because steamwebhelper requires that library and will not work without it.

(The good news is that steamwebhelper no longer uses steam-runtime-heavy, so that component is unused and will probably be removed in a future Steam release - so no changes will be needed in that part.)

Does the steam client really need to support PKCS? If yes, why exactly?

The Steam client probably doesn't have any particular need to support PKCS#11, but it's making use of a generic web engine, and that generic web engine has been designed to use an OS-provided libnss3 instead of reinventing SSL/TLS from first principles. This means it inherits all of the features, functionality, limitations and bugs of libnss3.

One of the features of libnss3 is that, if configured to load PKCS#11 modules, it will do that. You have configuration that directs it to load PKCS#11 modules, so it obediently loads them. Unfortunately, in the case of libbeidpkcs11.so, the result appears to be that it crashes with a null pointer dereference. This might indicate a bug in libbeidpkcs11.so, or it might indicate an incompatibility between library versions or an assumption being broken or something.

Replace libnss3 library with openssl so that the steam client does not support PKCS security modules anymore.

The Steam Runtime cannot simply do this. libnss3 and OpenSSL are incompatible libraries with different interfaces. Whichever one the developers of steamwebhelper have chosen to depend on, the Steam Runtime must provide that one.

Instead of developing their own web engine from first principles, the developers of steamwebhelper have chosen to use CEF, which depends on libnss3. This is a good thing - if Steam is going to display web content, it's better that it uses a web engine developed by web specialists and a cryptography library developed by security specialists, rather than doing its own thing that would likely contain security flaws.

It might be possible to configure or patch the Steam Runtime's libnss3 to disable the PKCS#11 feature. The cost of doing that is that when there are security fixes in libnss3 in Debian 11 (which is what the relevant branch of the runtime is based on), we won't pick up those fixes without manually merging.

smcv commented 5 months ago

According to https://wiki.debian.org/BeID, the Belgian-eID-specific fork of OpenSC was merged back into mainline OpenSC, so it might not be necessary to use libbeidpkcs11.so any more: the more generic opensc-pkcs11.so might be sufficient. Perhaps that would avoid this crash, while still allowing browsers to make use of the BeID card? Perhaps someone with access to the appropriate Belgian ID card could try that? Replacing country-specific software with an equivalent with worldwide applicability seems like it would increase robustness by avoiding having code paths that will not be seen by anyone outside Belgium.

This issue is probably specific to NixOS (and maybe Guix, which has a similar design) because on more ordinary distributions, the container environment that is used to run steamwebhelper isolates the container's /usr from the host's /usr, preventing libbeidpkcs11.so from being loaded. Because of some technical details of how NixOS works, this level of isolation is not feasible there, and instead we have a "leakier" container environment where /run/current-system/sw/lib ends up shared between host and container.

If steamwebhelper developers are confident that no libnss modules are desirable inside the container, another possible route would be to detect whether ~/.pki/nssdb exists, and if yes, "mask" it by mounting an empty filesystem over the top. We already use that trick to disable some sources of Vulkan layers. The cost of doing this is that if there is user configuration in ~/.pki/nssdb, that user configuration will be ignored for the steamwebhelper.

smcv commented 5 months ago

Or another possible route would be "mask" /run/current-system/sw/lib. What other categories of files end up in that directory? Are any of them regular files, or are they all symlinks to the hashed/content-based paths that are more commonly seen on NixOS?

MarkRijckenberg commented 5 months ago

@smcv: That is a genius solution I can live with :-) Thank you very much!

I have manually edited the eid-nssdb script and replaced libbeidpkcs11.so with opensc-pkcs11.so Then ran "bash eid-nssdb add" to avoid running the nix packaged version of eid-nssdb. Now steam does NOT crashloop during launch. So indeed, it seems that a bug in libbeidpkcs11.so is causing the crashloop of steam. opensc-pkcs11.so is not causing a crashloop. It's a eid-mw packaging issue after all, not a steam issue. I could log into www.cm.be using my eid card reader and using the Google Chrome web browser.

⋉ bash eid-nssdb add
NSS database: sql:/home/ulysses/.pki/nssdb
BEID library: /run/current-system/sw/lib/opensc-pkcs11.so
Adding Belgium eID to database:

WARNING: Performing this operation while the browser is running could cause
corruption of your security databases. If the browser is currently running,
you should exit browser before continuing this operation. Type 
'q <enter>' to abort, or <enter> to continue: 

Module "Belgium eID" added to database.

-----------------------------------------------------------
Name: Belgium eID
Library file: /run/current-system/sw/lib/opensc-pkcs11.so
Manufacturer: OpenSC Project                  
Description: OpenSC smartcard framework      
PKCS #11 Version 3.0
Library Version: 0.25
Cipher Enable Flags: None
Default Mechanism Flags: None

-----------------------------------------------------------
ulysses-desktop ~ ⋉ bash eid-nssdb show
NSS database: sql:/home/ulysses/.pki/nssdb
BEID library: /run/current-system/sw/lib/opensc-pkcs11.so
Displaying Belgium eID database entry, if any:
Note: this may fail if you don't have the correct permissions.

-----------------------------------------------------------
Name: Belgium eID
Library file: /run/current-system/sw/lib/opensc-pkcs11.so
Manufacturer: OpenSC Project                  
Description: OpenSC smartcard framework      
PKCS #11 Version 3.0
Library Version: 0.25
Cipher Enable Flags: None
Default Mechanism Flags: None

-----------------------------------------------------------
ulysses-desktop ~ ⋉
yoe commented 4 months ago

One of the features of libnss3 is that, if configured to load PKCS#11 modules, it will do that. You have configuration that directs it to load PKCS#11 modules, so it obediently loads them. Unfortunately, in the case of libbeidpkcs11.so, the result appears to be that it crashes with a null pointer dereference. This might indicate a bug in libbeidpkcs11.so, or it might indicate an incompatibility between library versions or an assumption being broken or something.

Did someone perhaps consider filing a bug report against https://github.com/Fedict/eid-mw with a reproducer or a patch? If there is a null pointer dereference, that probably does indeed indicate a bug in BeID, and we do take patches.

According to https://wiki.debian.org/BeID, the Belgian-eID-specific fork of OpenSC was merged back into mainline OpenSC, so it might not be necessary to use libbeidpkcs11.so any more:

This is not entirely accurate.

Yes, there was a BeID-specific fork of OpenSC once, and it was the preferred version of the BeID software at that point in time.

However, this fork is no longer maintained by anyone, and will also not work with Applet 1.8 cards, issued since ~2019. So unless your Belgian eID card is older than 5 years (at this point), you can't use OpenSC.

I will update that wiki page to reflect reality soon.

MarkRijckenberg commented 4 months ago

@yoe Thanks for your feedback. So I have opened following new issue: https://github.com/Fedict/eid-mw/issues/205

MarkRijckenberg commented 4 months ago

I have solved the crashlooping issue by performing a complete reinstall of the steam client on NixOS unstable.

I ran rm -rf ~/.local/share/Steam Then reran steam to force a new install. No more crashlooping of steam, even when libbeidpkcs11.so is loaded via eid-nssdb add