Re: cvs commit: openssl/crypto/dso dso_dl.c
On Fri, Nov 10, 2000 at 11:44:44PM +0100, Richard Levitte - VMS Whacker wrote: [Description of different locations for different modules deleted.] In this case, I'd say ENGINE_PATH would probably be the way to go that is reasonably simple to implement. I consider this as kind of agreement, that the DSO code will be change accordingly in the (near) future :-) Maybe the environment variable should have a better name like OPENSSL_ENGINE_PATH, for namespace reasons. Lutz.Jaenicke When OpenSSL is compiled, OPENSSLDIR could be recorded Lutz.Jaenicke and the engine could either go to OPENSSLDIR/lib (as Lutz.Jaenicke the normal openssl libraries, why not?) or into Lutz.Jaenicke OPENSSLDIR/engines (if an extra directory is being Lutz.Jaenicke preferred). Can't really do that. After all, if someone builds a program on top of libcrypto and makes use of the nCipher engine, should he or she, upon sending the program to the customer say "Oh, and to be able to use this, you have to move /opt/nfast/toolkits/hwcrhk/libnfhwcrhk.so to /usr/local/ssl/engine"? I don't think that's entirely fair. Of course, there are softlinks, at least under Unix, but I'm not very fond of soft ilnks... So it does not make sense to hardcode a default search path for engines into OpenSSL (in case OPENSSL_ENGINE_PATH is not set)!? Lutz.Jaenicke In a certain sense I am surprised as this discussion Lutz.Jaenicke only arouse because of the change to the HP-UX special Lutz.Jaenicke behaviour. What about other platforms? How is dynamic Lutz.Jaenicke loading realized there? With dlopen() and friends, searching along LD_LIBRARY_PATH is the default, as I understand it... This means that dlopen() must only be called with absolute pathnames (this is what the documentation on my Linux box at home says), otherwise LD_LIBRARY_PATH (and /etc/ld.so.cache and /usr/lib and /lib) are evaluated (the latter ones are system settings, so they should be ok from the security point of view). Until the change in the DSO code is being done, I think we should leave the +s switch for HP-UX enabled and have SHLIB_PATH evaluated in order to make life easier for application devlopers. (LD_LIBRARY_PATH is evaluated for dlopen() anyhow, so there is no additional risk involved for SHLIB_PATH.) Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: cvs commit: openssl/crypto/dso dso_dl.c
From: Lutz Jaenicke [EMAIL PROTECTED] Lutz.Jaenicke Please tell me how $ENGINE_PATH is more secure than Lutz.Jaenicke $SHLIB_PATH? Lutz.Jaenicke ENGINE_PATH is being explicitely processed by the Lutz.Jaenicke application (or inside the dso functionality). Lutz.Jaenicke SHLIB_PATH is processed by the system's dynamic Lutz.Jaenicke loader. The option to use SHLIB_PATH must be enabled at Lutz.Jaenicke compile time. Good point. Lutz.Jaenicke Anyhow, I have in the meantime had a look into Lutz.Jaenicke cyrus-sasl. They compile in a default path to look up Lutz.Jaenicke the authentication modules. This could be something we Lutz.Jaenicke do, too. If the library name is given completely Lutz.Jaenicke including the leading "/" (/path/to/dso_module), it can Lutz.Jaenicke be looked up directly. If only the engine name is Lutz.Jaenicke given, /default/path/dso_module is used. That looks Lutz.Jaenicke like a good solution to me. If DSO was only for the users of libcrypto. Unfortunately, it's also used from inside libcrypto (the engine code) to grab external crypto device libraries that may be place anywhere at the discretion of the vendor/implementor of said library. For example, for the nCipher/CHIL interface, the unixly path is /opt/nfast/toolkits/hwcrhk/libnfhwcrhk.so. On Windows I don't know where it is normally, but probably in c:\winnt\system32 for NT systems. I should know where the CryptoSwift library (libswift.so) usually lies around, at least on Linux, but I can't remember right now. With increased support for external devices, this kind of trouble will increase, especially if something might be in numerous places. In this case, I'd say ENGINE_PATH would probably be the way to go that is reasonably simple to implement. Lutz.Jaenicke When OpenSSL is compiled, OPENSSLDIR could be recorded Lutz.Jaenicke and the engine could either go to OPENSSLDIR/lib (as Lutz.Jaenicke the normal openssl libraries, why not?) or into Lutz.Jaenicke OPENSSLDIR/engines (if an extra directory is being Lutz.Jaenicke preferred). Can't really do that. After all, if someone builds a program on top of libcrypto and makes use of the nCipher engine, should he or she, upon sending the program to the customer say "Oh, and to be able to use this, you have to move /opt/nfast/toolkits/hwcrhk/libnfhwcrhk.so to /usr/local/ssl/engine"? I don't think that's entirely fair. Of course, there are softlinks, at least under Unix, but I'm not very fond of soft ilnks... Lutz.Jaenicke I get a bit depressed by this total lack of security Lutz.Jaenicke when loading shared libraries, don't you? Lutz.Jaenicke I am not that pessimistic. If we only load libraries Lutz.Jaenicke from "well known" locations (system locations like Lutz.Jaenicke /usr/lib or compiled in locations), the risk should be Lutz.Jaenicke under control. If somebody can tamper with the system Lutz.Jaenicke locations, its not openssl's fault any longer :-) Oh, I rather meant that there's no security wall between the application and the shared libraries it loads. I'm missing that quite a lot, and it would take away the trouble with LD_LIBRARY_PATH/SHLIB_PATH. Lutz.Jaenicke In a certain sense I am surprised as this discussion Lutz.Jaenicke only arouse because of the change to the HP-UX special Lutz.Jaenicke behaviour. What about other platforms? How is dynamic Lutz.Jaenicke loading realized there? With dlopen() and friends, searching along LD_LIBRARY_PATH is the default, as I understand it... -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] Chairman@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 Redakteur@Stacken \ SWEDEN \ or +46-709-50 36 10 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Software Engineer, Celo Communications: http://www.celocom.com/ Unsolicited commercial email is subject to an archival fee of $400. See http://www.stacken.kth.se/~levitte/mail/ for more info. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: cvs commit: openssl/crypto/dso dso_dl.c
On Tue, Nov 07, 2000, Mixmaster wrote: shl_load() also needs to load along a path given through an environment variable, SHLIB_PATH. This change makes that possible. Loading shared libs from SHLIB_PATH or LD_LIBRARY_PATH is a huge security hole. No security conscious program uses them Good catch. We obviously can't do that in OpenSSL. Would it work to have the Configure script figure out the correct path at compile time? __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: cvs commit: openssl/crypto/dso dso_dl.c
On Wed, Nov 08, 2000 at 10:15:36AM +0100, Richard Levitte - VMS Whacker wrote: From: Lutz Jaenicke [EMAIL PROTECTED] Lutz.Jaenicke I have not looked into the engine code. It should Lutz.Jaenicke however be possible to perform some string processing Lutz.Jaenicke inside OpenSSL to generate the complete pathname. That's something I've thought of, but not in the way you did... Lutz.Jaenicke Say, you check an environment variable "ENGINE_PATH" Lutz.Jaenicke and build $ENGINE_PATH/name_of_engine when calling Lutz.Jaenicke shl_load() Please tell me how $ENGINE_PATH is more secure than $SHLIB_PATH? ENGINE_PATH is being explicitely processed by the application (or inside the dso functionality). SHLIB_PATH is processed by the system's dynamic loader. The option to use SHLIB_PATH must be enabled at compile time. Anyhow, I have in the meantime had a look into cyrus-sasl. They compile in a default path to look up the authentication modules. This could be something we do, too. If the library name is given completely including the leading "/" (/path/to/dso_module), it can be looked up directly. If only the engine name is given, /default/path/dso_module is used. That looks like a good solution to me. When OpenSSL is compiled, OPENSSLDIR could be recorded and the engine could either go to OPENSSLDIR/lib (as the normal openssl libraries, why not?) or into OPENSSLDIR/engines (if an extra directory is being preferred). The OPENSSLDIR hierarchy is considered "secure", since if somebody can exchange libcrypto.sl, security is void anway :-) I however want to point out, that cyrus-sasl also offers an environment variable, SASL_PATH, that allows to override the compiled in default. However, like ENGINE_PATH I proposed this morning, this variable is evaluated by the SASL library itself to build the search path, it doesn't come near to the system loader. That doesn't mean that we have to come to the same conclusion. I get a bit depressed by this total lack of security when loading shared libraries, don't you? I am not that pessimistic. If we only load libraries from "well known" locations (system locations like /usr/lib or compiled in locations), the risk should be under control. If somebody can tamper with the system locations, its not openssl's fault any longer :-) I would hence recommend to change the default behaviour back to not search along SHLIB_PATH, compile in a default path and have the dso_loader build the pathname explicitely. An "OPENSSL_ENGINE_PATH" environment variable may be considered. In a certain sense I am surprised as this discussion only arouse because of the change to the HP-UX special behaviour. What about other platforms? How is dynamic loading realized there? Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: cvs commit: openssl/crypto/dso dso_dl.c
From: Mixmaster [EMAIL PROTECTED] mixmaster Loading shared libs from SHLIB_PATH or LD_LIBRARY_PATH is a mixmaster huge security hole. No security conscious program uses mixmaster them, and IMO that capability should be explicitly disabled mixmaster in OpenSSL and users should simply be required to provide mixmaster complete path names (starting with '/'). You're right about the risks. However, the engine code makes use of DSO to load the library that is relevant for the external device that is relevant. The only thing that can be sort of guaranteed about those is the name (like "cswift" for CryptoSwift, which should translate to "libcswift.so", "libcswift.sl" or "cswift.dll", depending on the OS). There's no real way to say exactly where each library will be, since that may be OS dependent (on some Unixen, the natural thing is to install under /opt, under others it's /usr/local). So, basically, we've chosen for now to go the easy, flexible way, so as not to cause too much trouble since there's no way we can predict how things are installed. If you have some ideas on how to solve that problem, please tell us. -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] Chairman@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 Redakteur@Stacken \ SWEDEN \ or +46-709-50 36 10 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Software Engineer, Celo Communications: http://www.celocom.com/ Unsolicited commercial email is subject to an archival fee of $400. See http://www.stacken.kth.se/~levitte/mail/ for more info. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: cvs commit: openssl/crypto/dso dso_dl.c
On Wed, Nov 08, 2000 at 09:45:24AM +0100, Richard Levitte - VMS Whacker wrote: From: Mixmaster [EMAIL PROTECTED] mixmaster Loading shared libs from SHLIB_PATH or LD_LIBRARY_PATH is a mixmaster huge security hole. No security conscious program uses mixmaster them, and IMO that capability should be explicitly disabled mixmaster in OpenSSL and users should simply be required to provide mixmaster complete path names (starting with '/'). You're right about the risks. However, the engine code makes use of DSO to load the library that is relevant for the external device that is relevant. The only thing that can be sort of guaranteed about those is the name (like "cswift" for CryptoSwift, which should translate to "libcswift.so", "libcswift.sl" or "cswift.dll", depending on the OS). There's no real way to say exactly where each library will be, since that may be OS dependent (on some Unixen, the natural thing is to install under /opt, under others it's /usr/local). So, basically, we've chosen for now to go the easy, flexible way, so as not to cause too much trouble since there's no way we can predict how things are installed. If you have some ideas on how to solve that problem, please tell us. I have not looked into the engine code. It should however be possible to perform some string processing inside OpenSSL to generate the complete pathname. Say, you check an environment variable "ENGINE_PATH" and build $ENGINE_PATH/name_of_engine when calling shl_load() and/or the application calls some engine_setup(shared_lib_path) and this shared_lib_path is then used when constructing the complete path name to the shared library... Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: cvs commit: openssl/crypto/dso dso_dl.c
[EMAIL PROTECTED] wrote: Modified:.CHANGES Configure crypto/dso dso_dl.c Log: shl_load() also needs to load along a path given through an environment variable, SHLIB_PATH. This change makes that possible. Loading shared libs from SHLIB_PATH or LD_LIBRARY_PATH is a huge security hole. No security conscious program uses them, and IMO that capability should be explicitly disabled in OpenSSL and users should simply be required to provide complete path names (starting with '/'). __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
