[stunnel-users] Linux FIPS compile libary question
jkemp at capwin.org
Fri Apr 11 16:07:22 CEST 2008
Thanks for the info. Turns out I caused my own problems. I added some features to stunnel that require ldap. That is what brought in the new openssl dependencies. I need to make a custom ldap library using the FIPS openssl libraries.
From: stunnel-users-bounces at mirt.net [mailto:stunnel-users-bounces at mirt.net] On Behalf Of Luis Rodrigo Gallardo Cruz
Sent: Thursday, April 10, 2008 5:32 PM
To: stunnel-users at mirt.net
Subject: Re: [stunnel-users] Linux FIPS compile libary question
On Thu, Apr 10, 2008 at 01:30:22PM -0400, Joe Kemp wrote:
> I guess the question is what will the linker do with a shared libssl
> in /lib and a static one in /usr/local/sslfips/lib. I ran the libtool
> with a -v. It gave tons of output and only had references to the
> library in /usr/local/sslfips.
> So I am going to assume I am seeing the dependencies of other
> libraries used by stunnel. For instance libldap needs openssl and
> uses the shared version. It's a little nerve-wracking ensuring FIPS
That sounds ... ugly. If your shared libraries can pull in a copy of libssl.so, you run the risk that some symbols might be resolved at run time against that copy, instead of against the static copy "inside"
the executable. Unless you were to link with -Bsymbolic, which is an advanced option invented with no other purpose than to trip inocent students of c linkage.
For this kind of stuff, I'd advice you to compile an stunnel with as few external libraries as you can get away with, and relink *all* those libraries to use your static libssl. Even better, get static libraries for them all and link against that.
> Is there a way to see just what the stunnel layer depends on? Ldd -v
> gave me more info but I am assuming it is still showing all levels of
> dependencies (stunnel's, libldap's, libsasl2, etc.).
objdump -x /usr/bin/stunnel |grep NEEDED gives you the list of sonames embedded in the executable. ldd tells you how the dynamic linker will resolve them to actual .so files.
More information about the stunnel-users