Dynamic linking (was Re: a point is being missed)

[jeremyp () gsms01 alcatel com au (Peter Jeremy)]

Michael B. Dilger <dilger () CS UCDAVIS EDU> wrote:
> Scott Barman <scott () Disclosure COM> writes:
> > It limits the attackable objects to one item, which can be secured far
> > better than the program plus EIGHT libraries currently being used by the
> > Solaris 2.4 login program.  What's easier to tie down, nine items or one?
>
> You're counting backwards.  Would you rather have 10 seperately programmed
> seperately compiled authentication modules (one for login, one for ftp,
> etc), or just one in a _shared_ library?
Not quite.  You _have_ to protect login, ftp, telnet, ... because
otherwise someone can just replace the executable.  With shared
libraries you _also_ have to worry about the shared libraries.  The
effort required to protect the system is increased by the number of
shared libraries required.  In the case of Solaris 2.4, /bin/login has
8 shared libraries, ftp and telnet have 6.  This means you have to
protect the 10 (or whatever) executables _and_ the 8 shared libraries
they use.

OTOH, having all the authentication code in one shared place would be
of benefit in terms of replacing the authentication code with
something different (and potentially stronger).  If it was just one
authentication library, and the location of the library was hard-coded
in the executable and couldn't be over-ridden, it might be OK.

There are advantages and disadvantages to shared libraries.  In some
cases, a dynamically linked executable is more appropriate, in other
cases a statically linked executable is more appropriate.
Unfortunately, Sun have chosen to not allow us that choice.

Peter
---
Peter Jeremy (VK2PJ)                    jeremyp () gsms01 alcatel com au
Alcatel Australia Limited
41 Mandible St                          Phone: +61 2 690 5019
ALEXANDRIA  NSW  2015                   Fax:   +61 2 690 5247