fix(docker): relocate libtcnative-1 to /srv/native-libs for correct FIPS removal#36071
Open
dsilvam wants to merge 3 commits into
Open
fix(docker): relocate libtcnative-1 to /srv/native-libs for correct FIPS removal#36071dsilvam wants to merge 3 commits into
dsilvam wants to merge 3 commits into
Conversation
SSLEngine=off alone is insufficient to prevent the OpenSSL 3.x crash on FIPS-enabled hosts. libtcnative-1 still loads libcrypto.so.3 and calls OpenSSL for non-SSL operations (e.g. random number generation), which triggers EVP_MD_get0_provider+0x4 SIGSEGV when the FIPS provider (fips.so) is missing from Ubuntu 24.04. The fix removes libtcnative-1.so at container startup when FIPS mode is detected, before Tomcat starts. This prevents the native library from loading OpenSSL entirely. Tomcat falls back to pure Java NIO/JSSE. libtcnative-1 remains installed by default for non-FIPS environments. Fixes #34212 Related: #34067, PR #34213
The previous approach (rm -f libtcnative-1.so) was silently a no-op: the container runs as UID 65001 (non-root) and cannot unlink root-owned files under /usr/lib. The || true masked the EACCES, making the fix invisible in logs while the JVM continued to crash. Instead, remove the AprLifecycleListener entry from server.xml at container startup when FIPS mode is detected. server.xml lives under /srv/dotserver/tomcat/conf/ which is owned by the dotcms user, so no root privileges are needed. Without the AprLifecycleListener, Tomcat never calls Library.initialize() and libtcnative-1 is never loaded, preventing libcrypto.so.3 from being touched entirely. Also adds a post-condition grep to fail loudly if the sed did not remove the listener, so failures are visible in container logs. Fixes #34212 Related: #34067, PR #34213
The server.xml AprLifecycleListener approach was insufficient because setenv.sh sets java.library.path=/usr/lib/<arch>-linux-gnu/ and Tomcat auto-detects and loads libtcnative-1 from there regardless of server.xml. Root cause: On a FIPS-enabled kernel, OpenSSL 3.x requires fips.so before allowing any crypto operation. Ubuntu 24.04 does not ship fips.so, so the first OpenSSL call (EVP_MD_get0_provider) segfaults at the native level. Fix: - Dockerfile: move libtcnative-1.so.0* to /srv/native-libs/ (dotcms-owned) and leave symlinks in /usr/lib/<arch>-linux-gnu/. This is done as root during the image build — no runtime root access required. - FIPS script: when FIPS detected, rm /srv/native-libs/libtcnative-1.so.0* (writable by dotcms user). The symlinks in /usr/lib become dangling so dlopen() cannot load the library regardless of java.library.path. Non-FIPS containers are unaffected: symlinks resolve normally, the library loads and provides its usual performance benefits. Fixes #34212 Related: #34067, PR #34213
wezell
approved these changes
Jun 9, 2026
wezell
left a comment
Member
There was a problem hiding this comment.
Ok, hate this complexity but looks like it could work.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Supersedes PR #35777 which was merged but proved insufficient in customer testing.
The previous fix (removing
AprLifecycleListenerfromserver.xmlat runtime) did not prevent the crash becausesetenv.shsets-Djava.library.path=/usr/lib/<arch>-linux-gnu/and Tomcat auto-detects and loadslibtcnative-1from that path regardless ofserver.xmlconfiguration.Root cause confirmed: On a FIPS-enabled kernel (
fips_enabled=1), OpenSSL 3.x requires the FIPS provider module (fips.so) before allowing any cryptographic operation. Ubuntu 24.04 does not shipfips.so. The first OpenSSL call —EVP_MD_get0_providerfor random number generation insidelibtcnative-1— segfaults withSIGSEGVinlibcrypto.so.3. This occurs even withSSLEngine=offand even withoutAprLifecycleListenerinserver.xml.Changes
Dockerfile: During image build (as root), movelibtcnative-1.so.0*from/usr/lib/<arch>-linux-gnu/to/srv/native-libs/(owned by thedotcmsuser) and leave symlinks in/usr/lib. Works on bothamd64andarm64via$(uname -m).15-detect-fips-and-set-ssl-engine.sh: When FIPS detected,rm /srv/native-libs/libtcnative-1.so.0*(writable bydotcmsuser). The symlinks in/usr/libbecome dangling sodlopen()cannot load the library regardless ofjava.library.pathorserver.xml. Includes a post-condition check that logs loudly on failure.Non-FIPS containers are unaffected: symlinks resolve to the real files normally and the library loads, preserving performance.
Test plan
libtcnative-1must still load (AprLifecycleListener - Loaded Apache Tomcat Native library),CMS_SSL_ENGINE=on/proc/sys/crypto/fips_enabled=1, e.g. RHEL 8 with CIS Level 2) — container must start withoutSIGSEGV, log must showlibtcnative-1 removed from /srv/native-libsls /usr/lib/<arch>-linux-gnu/libtcnative-1.so.0*on FIPS container shows dangling symlinksls /srv/native-libs/on FIPS container is empty after startuparm64image build succeeds (symlink path usesaarch64-linux-gnu)Related
Closes #34212
Related: #34067, PR #34213, PR #35777, Freshdesk ticket #34489