Linux FIPS compile libary question
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. Configure with: ./configure --with-ssl=/usr/local/sslfips112 --enable-fips --disable-libwrap Make's linker line: /bin/sh ../libtool --tag=CC --mode=link FIPSLD_CC=gcc /usr/local/sslfips112/bin/fipsld -g -O2 -Wall -Wshadow -Wcast-align -Wpointer-arith -I/usr/local/sslfips112/include -lldap -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 -lz -ldl -lutil -lnsl -lpthread -L/usr/local/sslfips112/lib -lssl -lcrypto 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.
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.
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:[email protected]] Sent: Thursday, April 10, 2008 1:25 PM To: Joe Kemp Cc: [email protected] 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.
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 compliance.
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.
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. Thanks again. -Joe -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Luis Rodrigo Gallardo Cruz Sent: Thursday, April 10, 2008 5:32 PM To: [email protected] 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 compliance.
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.
Hello, expert: I have a question. Can stunnel be used behind a router without the router forwarding the port number? Recently I found one VNC can work this way. Was wondering whether you can modify the config. file to make it work. right now I set (serverside) the router forwarding port 8888 to the desktop, the stunnel on the desktop listening for port 8888 and forward this stream 8888 to VNC's 5955. My purpose is to bypassing the router forwarding part. Thanks for any input. J 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. Thanks again. -Joe -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Luis Rodrigo Gallardo Cruz Sent: Thursday, April 10, 2008 5:32 PM To: [email protected] 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 compliance.
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. _______________________________________________ stunnel-users mailing list [email protected] http://stunnel.mirt.net/mailman/listinfo/stunnel-users -- Internal Virus Database is out-of-date. Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 269.22.5/1357 - Release Date: 4/3/2008 10:48 AM
I do not think is possible to avoid the port forwarding part. Your router will stop the incoming packets and they will never reach the stunnel service listening for connections. Sometimes, people uses th VNC client in listening mode, reversing who initiates the connection. In listening mode the server initiates the connection. however, this puts the firewall issue on the client side instead of the server. --- jz <[email protected]> wrote:
Hello, expert:
I have a question. Can stunnel be used behind a router without the router forwarding the port number? Recently I found one VNC can work this way. Was wondering whether you can modify the config. file to make it work.
right now I set (serverside) the router forwarding port 8888 to the desktop, the stunnel on the desktop listening for port 8888 and forward this stream 8888 to VNC's 5955.
My purpose is to bypassing the router forwarding part.
Thanks for any input.
J
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.
Thanks again. -Joe
-----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Luis Rodrigo Gallardo Cruz Sent: Thursday, April 10, 2008 5:32 PM To: [email protected] 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 compliance.
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. _______________________________________________ stunnel-users mailing list [email protected]
http://stunnel.mirt.net/mailman/listinfo/stunnel-users
-- Internal Virus Database is out-of-date. Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 269.22.5/1357 - Release Date: 4/3/2008 10:48 AM
BEGIN:VCARD VERSION:2.1 N:zhang;jilin FN:jilin zhang NICKNAME:J ORG:Ellington & Associates TITLE:Geologist TEL;WORK;VOICE:7139562838 TEL;WORK;FAX:7139562840 ADR;WORK:;;1022 Wirt Road, Suite 312;Houston;Texas;77055;US LABEL;WORK;ENCODING=QUOTED-PRINTABLE:1022 Wirt Road, Suite 312 Houston Texas 77055 US URL:www.ellingtongeologic.com EMAIL;PREF;INTERNET:[email protected] X-WAB-GENDER:2 REV:20080417T113641Z END:VCARD _______________________________________________ stunnel-users mailing list [email protected]
http://stunnel.mirt.net/mailman/listinfo/stunnel-users
____________________________________________________________________________________ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
participants (4)
-
Algol Tradent -
Joe Kemp -
jz -
Luis Rodrigo Gallardo Cruz