Re: a point is being missed

[casper () Holland Sun COM (Casper Dik)]

> (What's "static dynamic linking"?)  Who's "we"?  I notice you're
> sending from a sun.com address, so I assume "we" is Sun (er, SunSoft,
> whoever).  In that case, "we can't do that" is just false.  You (they)
> may not be willing to, but there is no reason why a libdl.a couldn't
> exist, with full functionality, mapping ld.so the first time it's
> needed.

Let me say first that I don't speak for SunSoft.  This doesn't
change the fact that it is nearly impossible to do static linking
on Solaris 2.x.  (And static dynamic linking is a slip of the keyboard).

I have not yet seen any good arguments against dynamic linking.
Environment variables and other environmentel tricks have always been
possible in Unix.  The LD* variables have made the need for
environmental control much more obvious.  su/login/sendmail didn't
do proper cleanup and passed almost any environment variable to
sub processes.  That was not a problem introduced by dynamic linking.
It was a problem that had existed for a long time but that had gone largely
unnoticed.  Even $TERM is dangerous in some circumstances.


> However, there is no reason why this has to be so.  One option is to
> always create the dynamic-linker structures.  Another is to create them
> in the presence of an option, which is documented as being necessary
> for libdl.a to work.  Or perhaps ld could do it upon the presence of
> some indication in the files being linked, such as a reference to an
> undefined external called __ld_dynamic_stabs.  Another way would be to
> teach ld to effectively do what ld.so does, so that it can take a .so
> file as a library even when doing a static link - and when it does so,
> have it create dynamic-linker structures in the resulting executable.
> (I've often wished for a tool that would take a dynamically linked
> a.out, chase down the .so files necessary, merge everything, and write
> out a new a.out that is effectively statically linked.  I've even
> speculated about writing one, even though I really don't know enough
> about the dynamic linker at present.)

First of all: all authentication programs are extensible through dynamic
linking, all localized programs are extensible through dynamic linking,
etc.  Dynamic linking is required.

Now what about libdl.a?

By putting libdl.a in a program you don't fix anything: you again have code
that searches LD_LIBRARY_PATH or even honors LD_PRELOAD.

What have you gained?  You still are vulnerable to the same problems
and all you have done is spend countless man hours to make /usr/lib/ld.so
into a libdl.a (libdl.so isn't a library), changing ld, etc.


> I would argue, though, that an even better solution is to redesign the
> symbol-table mechanism.  Just move the symbol table into the text
> segment and it's always available in any executable.  Besides, doing
> that reduces the disk space wastage that arises in the current scheme
> from storing a symbol table in the usual a.out place and then storing
> another copy of the symbol table, in a different layout, as part of the
> executable's loaded segments.  With a little care in the <a.out.h>
> macros like N_SYMOFF and N_STROFF, existing code should even work with
> this scheme, assuming it's well-behaved (basically, that it uses said
> macros and doesn't need to grow either segment).

This I agree with: there's no need to waste all that space.

> No, I'm sorry, Sun may be unwilling to go to the trouble to link login
> static (and indeed, they probably are - they've demonstrated an
> unwillingness to go to any sort of trouble for the sake of security
> until prodded by wide publicity of a problem).  But claiming that
> they're unable to just doesn't hold up.

You're being unfair.  Sun is pretty open about security.  We publish
security patches for problems not widely know.

Besides, I don't share you opinion that linking login statically contributes
to the security of Solaris 2.x.

In Solaris 2.6, what would you rather have: a statically linked login or
a totally dynamically configurable login?

Casper