Re: cvs commit: openssl/crypto/dso dso_dl.c

[Richard Levitte - VMS Whacker]

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]