[ On Wednesday, December 19, 2001 at 12:16:06 (+0000), Sean Witham wrote: ]
> Subject: Re: [Exim] Exim and IBM DB2
>
> The point is I think your fears in weakness in new code in exim that
> uses dlopen are valid BUT at the end of the day only personal
> judgement can be used to decide if the extra risk is outwayed by the
> extra functionality it provides. Its a risk/cost assestment issue,
> everyone will come to their conclusions based on their own
> requirements. I think your only concern should be that exim does not
> compile in such code by default and that users are informed of all
> known protential risks (and told this is the KNOWN potential risks).
You've forgotten one of the big threats on the public Internet today.
That is the failure of other people to do reasonable risk assessment.
We're not talking about something that exists on its own in isolation,
but rather a component of a very tightly integrated community.
I don't want a commonly used program to even give people the opportunity
to hang themselves, because in doing so they may harm others as well
(and I'm one of those "others"! :-) In the real world analogy you are
free to take any personal risks you think you'll survive, but if your
demise triggers mine then you've gone too far -- you have no "right" to
take such risks. In the Internet if your compromised system somehow
affects my ability to "safely" use the public Internet (or even worse
causes my system(s) to be vulnerable), then you've gone too far in
taking risks with your systems. Since we have no centrally administered
system of rights and laws for Internet users I'm attempting to use peer
pressure and what logic I can muster to influcence decisions. (It's
already bad enough that zillions of people unknowingly run
vulnerable-by-default M$ systems on permanent "broadband" connections
forcing everyone with more sense to defend themselves from them once
they inevitably become compromised.)
> I agree any program that uses dlopen faces the same risks and
> responsabilities that ld.so does.
You're still failing to see that dlopen() increases the risk over ld.so
simply because it allows re-introduction of new code AT ANY TIME. This
makes vulnerabilities that may not have been otherwise exploitable (at
least not exploitable to any significant gain) suddenly as bad as the
worst buffer-overflow bug possible. dlopen() is a slippery slope. It
starts out at a 45 degree angle all covered in grease and if your code
as any even tiny vulnerability, even anywhere else in the program
(i.e. far away from where it uses dlopen()) then the slope simply
increases until some attacker makes it 180 degrees upside down and you
fall off no matter how secure you think you are. (A spider fell from my
ceiling into my hot bath the other day because the steam eventually made
the paint too slippery for even its most carefully placed eight feet to
hold on! I was watching it with interest because it was obviously in
distress for some time, looking for a place with more secure footing. I
only took my eyes off it for a moment and when I looked back it had
disappeared. Luckily I'm not too squeamish, and luckily I didn't have
too many suds to hide it yet, and even better the bath was too hot for
it anyway so it was dead before it came into contact with me. ;-)
> > What's really stupid about this whole idea is that a program like
> > exim need never ever in a million zillion years load plugin code --
>
> It supports pipes, it does so safely by throwing away privledges, why
> not apply this approach to plugin code. It also supprts embeded perl,
> I haven't looked at that yet though. Why should it not offer plugins
> and a build time option ?
"plugins" that employ pipes are called separate stand-alone programs.
I use the term "plugin" explicitly to refer to an API that can be
accessed by a running process by way of dlopen(). I believe this is the
most widely accepted definition in software engineering terminology.
> O.K. as long as you have compiled in the stubs to exim, what if you
> have a new library ? This guy wants to add a new library to 50
> machines without have to reinstall exim 50 times.
You have to copy some file to all those 50 machines no matter what that
file includes. You have to instruct exim to do something with that file
on every of those 50 machines no matter how you implement the mechanism.
Copying a new shared library to 50 machines and restarting exim on every
one is no more difficult than copying a plugin module to those 50
machines and then instructing those 50 exim master processes to reload
the plugin. The difference is that with a shared library you have the
relative safetly of risking ld.so's execution only during the initial
loading of the exim process and you don't have to worry about any other
vulnerability exposing you to loading of foreign code via dlopen() after
the process has started.
What's really silly and stupid in this case though is that it's also
just as easy to install a new static-linked exim binary on all those 50
machines and then restart all 50 exim master processes (doesn't exim
even automaticaly restart itself if it finds its binary image file has a
new timestamp?). You can re-compile and statically re-link exim just as
easily as you can build a new shared library for it. Easier and with
more certainty in fact if you take testing and Q/A into the equation.
What you're talking about here are systems management issues TOTALLY
unrelated to how any given program's internals work (and that's what
plugins and even shared libraries amount to -- internals). If you have
50 similar/identical machines to manage then either you need a
sufficient number of obedient monkeys to manipulate them, or you need a
set of well defined processes and procedures to automate your
management. Anything you have to do more than once should be automated,
but of course in an appropriately secure and reliable manner.
Reinstalling an exim binary package 50 times should be the very least of
your problems in this endeavour. That's simply the final deployment
action that comes after all the development and testing. Whether you do
it once, 50 times, or 100 times, is irrelevant because it's something
you MUST be prepared to do for any number of other reasons anyway. If
you think any kind of internals implementation technology with ease your
systems management problems then you are seriously confused.
> Plugins are needed when the application wishes to prived the ability
> to extend it with new functionality in advance of know what the new
> functionaly is !
No, they are NOT. You do not even need shared libraries. Even if Exim
were a proprietary program it could be delivered as relinkable .o files
and you could hook in any local code you wanted (or even replace
internal parts if their API were published. As it is though you've got
the source and you can make any change -- not just linking it with a
different library.
PLEASE do not EVER confuse start-time or run-time dynamic linking
features with plain old extensibility. You have been blinded by the
misapplication of fancy new technology that is TOTALLY inappropriate for
the requirements in this situation.
Plugins are NEVER necessary in this situation, and they are quite
obviously very dangerous to boot. Exim is not a kernel. Exim is not a
real-time system. Exim is not a gargantuan proprietary multi-media
end-user application. It would be literally stupid for Exim in anything
remotely resembling its current form to ever even try to use dlopen().
Please learn a little bit more about systems programming and software
engineering before you disseminate any more patently false claims like
that. Sorry for reducing this to what no doubt amounts to a personal
attack, but this has gone WAY too far. A blue sky dream is one thing,
but this is a very real-world problem that can be trivially solved in
the same way it's been solved nearly forever in this industry. If you
are blinded by false claims of the joys of inappropriate technology you
can only make mistakes. Since your mistakes will affect the abilities
of others to use the Internet then you must be "encouraged" not to make
such mistakes in the first place, and others must be "encouraged" not to
even give you the ability to make such mistakes in hopes that you won't
go through the motions of giving yourself such ability either.
All you're really looking for are APIs for easy hooks into appropriate
places in Exim so that you can extend/replace the way it does certain
operatoins. Philip has created one such hook API as an experiment and
has offered to extend this feature to other internal operations if it
proves successful. This is far more than you should ever expect from
any "open source" product since in reality you are allowed (and should
be prepared and able) to go in and directly modify the program to work
in the way you wish it to work. In this case a hook API is simply a
form of internal documentation that makes your job easier.
--
Greg A. Woods
+1 416 218-0098; <gwoods@???>; <g.a.woods@???>; <woods@???>
Planix, Inc. <woods@???>; VE3TCP; Secrets of the Weird <woods@???>
