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]
