[ On Wednesday, December 19, 2001 at 12:23:39 (-0500), Theo Schlossnagle wrote: ]
> Subject: Re: [Exim] Exim and IBM DB2
>
> So, if ld.so makes a mistake, your screwed. If dlopen() is called and
> you see that any things is suspect, you exit before anything bad
> happens. You have no risk (if you code it right) of any code just
> "executing" when you call dlopen()). _init would run, if you were so
> careless to dlopen() an object with _init in it. So, don't.
You, the original developer and programmer, may not be the one calling
dlopen(). Perhaps people who have not actually played "Core Wars" can't
appreciate the full ramifications of the Unix process security model.
> So much clearer! Thank you. I completely agree with you. But, you
> stance is different from mine. If someone can buffer overflow Exim
> there is a security problem. If someone can convince dlopen() to load
> the wrong code, it is a security problem. Address the problems, don't
> avoid using techniques because current supporting implementations are
> flawed -- they can be fixed. That is a good approach to make no new
> advances.
The problem, in both cases, is that foreign code can be introduced to a
running (privileged) process.
You solve the buffer overflow problems by eliminating bugs and by using
"fail-safely" programming techniques.
You can only solve the dlopen() problem by not allowing your process to
use dlopen() in the first place. You do not need it. You do not want
it. DO NOT use it.
> I said ~0% use static linking. I use static linking all the time too.
> It is just silly for things like Exim. It uses openssl and libdb and
> openldap... All my other programs do too. What a waste of system
> resources. There are times and places for static linking -- and it is
> always an option for the paranoid. I have nothing against it.
Waste? What are you talking about? Resource usage is supposed to be
part of your cost equation when you do your risk assesment. As Yoda
might say, there is no "waste".
You should also learn to properly evaluate the cost/benefit ratio of
dynamic linking. In my experience most people don't do it properly, and
in most cases the result is not intuitive. You must actually make
scientific measurements to be sure you've got the right result.
Having gone back to totally statically linked systems for some
situations I can assure you that the supposed benefits of dynamic
linking, especially where you have one large binary that's often
restarted quite frequently but has always one instance running, are very
different than a naive person might otherwise assume given the often
blatantly false propoganda spread far and wide by proponents of dynamic
linking. In fact explicitly in the case of programs like mailers and
web servers (eg. monolithic daemons that have many running instances),
static linking can actually result in as much as 30% or more performance
_improvement_ (and depending on the number of exec()s, up to 70%), and
much of that comes from reduction of I/O load on the system disks (i.e.
the filesystems where the programs, ld.so, libraries, etc.) reside.
> Perl embedding suffers from ALL of the same problems, because the perl
> interpreter brings -ldl with it.
Yes, exactly (well it doesn't have to bring dlopen() with it, but it
usually does). Perl is a very poor choice for any such task anyway.
--
Greg A. Woods
+1 416 218-0098; <gwoods@???>; <g.a.woods@???>; <woods@???>
Planix, Inc. <woods@???>; VE3TCP; Secrets of the Weird <woods@???>
