Can I rename the OpenSSL shared objects for FIPS?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Can I rename the OpenSSL shared objects for FIPS?

gperrow

We are shipping OpenSSL (1.0.2j)  shared objects built with FIPS, which are automatically loaded when the application starts. But if our software directory is in the path (or LD_LIBRARY_PATH or platform equivalent) earlier than the system directories, then other applications that load OpenSSL dynamically (eg. ssh on some systems) could use our libraries rather than the system ones. This is not a huge deal except that we may want to disable certain algorithms that we don’t use, and we don’t want to break system utilities that do use them.

 

We would like to avoid this by renaming these libraries, i.e. libMYcrypto.so.1.0.0 and libMYssl.so.1.0.0, and then we’ll know that only our application would load them. Simply renaming the files is obviously no good, and I’ve found that renaming them before linking with them does not work either.

 

It would seem that the names “libcrypto” and “libssl” are hard-coded in a million places within Makefiles and scripts and such. Is there a way to solve this problem? This would apply to Linux, HP-UX, and Solaris.

 

Thanks

Graeme Perrow

 


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Can I rename the OpenSSL shared objects for FIPS?

Benjamin Kaduk
On 01/12/2017 02:10 PM, Perrow, Graeme wrote:

We are shipping OpenSSL (1.0.2j)  shared objects built with FIPS, which are automatically loaded when the application starts. But if our software directory is in the path (or LD_LIBRARY_PATH or platform equivalent) earlier than the system directories, then other applications that load OpenSSL dynamically (eg. ssh on some systems) could use our libraries rather than the system ones. This is not a huge deal except that we may want to disable certain algorithms that we don’t use, and we don’t want to break system utilities that do use them.

 

We would like to avoid this by renaming these libraries, i.e. libMYcrypto.so.1.0.0 and libMYssl.so.1.0.0, and then we’ll know that only our application would load them. Simply renaming the files is obviously no good, and I’ve found that renaming them before linking with them does not work either.

 

It would seem that the names “libcrypto” and “libssl” are hard-coded in a million places within Makefiles and scripts and such. Is there a way to solve this problem? This would apply to Linux, HP-UX, and Solaris.

 


The full SONAME is used at runtime linking to locate the correct library to use, so you may have an easier time just setting the library version number to something unlikely to conflict with an official release -- that's just a one-line change in crypto/opensslv.h, SHLIB_VERSION_NUMBER.

-Ben

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Can I rename the OpenSSL shared objects for FIPS?

Eichenberger, John-2
In reply to this post by gperrow

I actually submitted a patch set that renames library files during the build process once upon a time… but it was summarily rejected without any real attention paid to it.  My change was specific to building dynamic libraries for Windows/WinCE… but the same idea would apply to other target builds I think.  One has to get into the perl scripts to make it happen.

 

-Ike-

  John Eichenberger

Intermec by Honeywell
Principal Engineer: Sustaining Engineering

425.921.4507

 

From: openssl-users [mailto:[hidden email]] On Behalf Of Perrow, Graeme
Sent: Thursday, January 12, 2017 12:10 PM
To: [hidden email]
Subject: [openssl-users] Can I rename the OpenSSL shared objects for FIPS?

 

We are shipping OpenSSL (1.0.2j)  shared objects built with FIPS, which are automatically loaded when the application starts. But if our software directory is in the path (or LD_LIBRARY_PATH or platform equivalent) earlier than the system directories, then other applications that load OpenSSL dynamically (eg. ssh on some systems) could use our libraries rather than the system ones. This is not a huge deal except that we may want to disable certain algorithms that we don’t use, and we don’t want to break system utilities that do use them.

 

We would like to avoid this by renaming these libraries, i.e. libMYcrypto.so.1.0.0 and libMYssl.so.1.0.0, and then we’ll know that only our application would load them. Simply renaming the files is obviously no good, and I’ve found that renaming them before linking with them does not work either.

 

It would seem that the names “libcrypto” and “libssl” are hard-coded in a million places within Makefiles and scripts and such. Is there a way to solve this problem? This would apply to Linux, HP-UX, and Solaris.

 

Thanks

Graeme Perrow

 


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users