[stunnel-users] Linux FIPS compile libary question

[Joe Kemp]

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 compliance.  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.).

-----Original Message-----
From: Luis Rodrigo Gallardo Cruz [mailto:rodrigo at nul-unu.com]
Sent: Thursday, April 10, 2008 1:25 PM
To: Joe Kemp
Cc: stunnel-users at mirt.net
Subject: Re: [stunnel-users] Linux FIPS compile libary question

On Thu, Apr 10, 2008 at 12:44:39PM -0400, Joe Kemp wrote:
> I am compiling stunnel on Centos 5 that has a regular Openssl 0.9.8b rpm installed.  I have put my FIPS openssl in /usr/local/sslfips112.

> FIPSLD_CC=gcc /usr/local/sslfips112/bin/fipsld -g -O2 -Wall -Wshadow
> -Wcast-align -Wpointer-arith -I/usr/local/sslfips112/include -o
> stunnel file.o client.o log.o options.o protocol.o network.o
> resolver.o ssl.o ctx.o verify.o sthreads.o stunnel.o auth.o pty.o
> libwrap.o -lldap -lz -ldl -lutil -lnsl -lpthread
> -L/usr/local/sslfips112/lib -lssl -lcrypto

> This builds a stunnel that seems to run fine.  During startup it says
> "stunnel is in FIPS mode."  But if I run "ldd stunnel" it shows it
> needs /lib/libssl.so.6.  While stunnel is running lsof shows it has
> that library open also.  Why does my FIPS stunnel build still use the
> 0.9.8b shared library?  Shouldn't all of the ssl dependencies been
> handled by the static FIPS openssl library during linking?  The same
> issue exists for libcrypt.

I've never tried to compile a FIPS binary, so this might all be wrong. Grains of salt recommended.

The basic issue is that -lssl doesn't just mean "use libssl.so to resolve symbols while linking". It *also* means "store libssl.so in the table of needed libraries in the final executable". Mostly because the linker has no way of knowing _a priori_ if the executable will eventually try to access some symbol from the library that was not evident during the link (think dlopen)

Adding -Wl,--as-needed to the linker line *ought* to solve this, by telling the linker to only add entries to the needed table for dynamic libraries whose symbols are explicitely required during the link. Beware that libtool likes to reorder args to the linker, and it seems to like putting this option at the end, where it becomes useles. There's a patch at http://bugs.debian.org/347650 that might help with that, but it's not quite for the faint-hearted.

Good luck.