[49] in WWW Security List Archive
RE: GSS API (as a DLL)...
daemon@ATHENA.MIT.EDU (Ramin Firoozye)
Wed Aug 17 18:32:51 1994
From: rpa@netcom.com (Ramin Firoozye)
To: www-security@ns1.rutgers.edu
Date: Wed, 17 Aug 1994 11:03:29 -0700 (PDT)
>
> I apologize for this tangential issue, but somebody has expressed
> concern that a Dynamic Link Library type mechanism for the GSS APIs (or
> DLLs in general) are not suitable because there is not wide support on
> many Unix systems. This is the first time I have heard this concern
> and I wanted to make sure we're not going down a road of woe and despair.
>
> Could somebody with experience on the interesting Unix platforms
> comment on this concern?
>
No, DLL's in their incarnation under Windows do not exist under Unix.
However, there is a somewhat similar mechanism that allows object files
to be dynamically loaded into the process address space, and symbols
in the object file resolved at runtime. The entry point for a routine is
just another symbol so you can access it and call it by dereferncing a
pointer to the function.
The DLD mechanism is quite popular since it is generally available via
standard GNU depositories. Packages like Postgres, TCL, and the new
Perl 5.0 use DLD (or similar mechanisms) to allow add-on subsystems to be
provided at runtime. Sun's Solaris and SGI's Irix have their own
complementary schemes (dlXXX routines) that basically work the same way.
The only major difference between Unix-based "dynamically loaded object
files" and Windows DLL's is that DLL's are known by Windows to be position
independent, hence only one copy of them is loaded into memory at a time
and there are definite rules as to memory access within DLL's. The Mac
has always had the runtime loadable segments that software like Photoshop
and Hypercard have used as plug-ins's and XCMD's. But they don't provide
the memory advantage of DLL's (i.e. only one copy in memory at any time).
The Power-PC version of MacOS provides support for a Component Manager
that provides OS support for DLL's.
The main problem in using plug-in's for security functions is that the
interface to the "plug-in" has to be etched in stone ahead of time, in such
a way that future algorithms can work without any software recompilation
necessary. This implies that the interface between the "caller" and the
DLL better be designed with some sort of request/reply mechanism that
allows for challenge/response based security mechanisms. In dynamic
component lingo, you really want a "resource discovery" capability built
into DLL's so they can tell the caller what they can do and how the caller
can go about getting them to do something.
The BIG problem specific to security DLL's is that someone bent on breaking
security can write a "wrapper" DLL around a security DLL, store all the
stuff it gets from the caller, pass on the result onto the actual DLL and store
away the replies as well before passing the reply back up to the caller.
In other words, it becomes much easier to implement a "spoof the login"
type scheme.
There are other problems with DLL's as well which should probably be discussed
offline (:-)
Cheers,
Ramin.
--
Ramin Firoozye'
rp&A Inc. - San Francisco, California
Internet: rpa@netcom.COM - CIS: 70751,252
--
