On Mon, 15 Sep 2003, Greg A. Woods wrote:

: One of the major security-related features of static-linked programs is
: that the processes they run as _cannot_ dynamically load new code.

I really need to get the number of your dealer.  He sells the Good Stuff.

It has been demonstrated many times that proliferation of static binaries is
*detrimental* to security maintenance, because they require recompilation to
gain fixes to libc (and other dependent libraries).  Sun has talked at
length about this issue, as has TNF and countless others.

The only security problem with dynamic linking has been with programmer
error -- relating to things such as setuid binaries, which are specifically
forbidden from running arbitrary code via LD_PRELOAD/LD_LIBRARY_PATH and the
like.  These were bugs in the dynamic linker which needed to be fixed; these
were *not* evidence that dynamic linking was somehow bad for security.

Demonstrated fallacy.  Next argument?

: That said though it must also be said that the vast majority of "plugin"
: code that has to run in the same context and address space as the caller
: is just an example of bad design.

A matter of perspective and experience; much research has also focused on
how modular code is actually *better* design.  So, this is a red herring.
Next argument?

: Note that often in general purpose unix environments the cost of static
: linking is easily offset by the savings gained from not having to run
: ld.so on every invocation, and that goes double for anything which calls
: the real dlopen() too.

This is a cost that has been accepted by OS developers for some time,
insofar that it has many benefits (not just size of binaries) -- see my
comment about security, above.

Thus, this is irrelevant, as Unix systems are not going back the other way
to statically linking huge parts of the system just for a minor performance
boost.  Next argument?

-- 
-- Todd Vierling <tv@duh.org> <tv@pobox.com>