[ On Sunday, December 30, 2001 at 22:24:41 (-0800), Bill Studenmund wrote: ]
> Subject: Re:   RFC: migration to a fully dynamically linked system
>
> Dynamic linking means that company X can produce security dongle Y and
> auth module Y.so, and ship it. A customer can follow the simple HOW_TO and
> install it (put Y.so somewhere sane, tell nsswitch how to find it, and set
> which lookups use it).

Company X can also produce an auth module "Y.o" and ship it with copies
of the original system ".o" files and a tiny C fragment containing a
switch table entry and the end user need only run a simple shell script
to build a new statically linked authentication daemon containing the
new Y.o and all the other auth modules from companies "A-W" and "Y" and
"Z" too, and then configure his or her /etc/nsswitch.conf to use them in
the desired way and finally simply re-start the daemon and authenticate
away.

Dynamic linking doesn't realy add much benefit even in scenarios where
proprietary code is involved, and it may even introduce many more
potential security hazards (as we've discussed already many bugs become
much more trivial to exploit in a dynamically linked program, and when
that same program can dynamically load new code a successful exploit can
become much more difficult to detect too).  Imagine if CodeRed didn't do
anything really visibly nasty, but just sat there much more quietly as a
thread in the already running web server, not affecting the main
operation of the daemon?  Millions of copies would still be running
under control of the attacker(s) today.  A paranoid person would assume
that such a smart worm was already lurking in every vulnerable system!  ;-)

-- 
								Greg A. Woods

+1 416 218-0098;  <gwoods@acm.org>;  <g.a.woods@ieee.org>;  <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>