[ On Friday, January 28, 2005 at 08:54:21 (-0800), Jason Thorpe wrote: ]
> Subject: Re: static vs. dynamic runtime linking, esp. for citrus (was PAM and su -K)
>
> 
> On Jan 28, 2005, at 1:57 AM, Joerg Sonnenberger wrote:
> 
> > This argument is just ridiculus. Nothing prevents an application from
> > using dlopen-like mmaps at all.
> 
> Exactly.  And on some popular platforms (like i386), it's also very 
> difficult to prevent the execution of arbitrary mmap'd code.

Some platforms, currently, but not all platforms.

Literally preventing the execution of arbitrary mmap()'d code vs. making
it much more difficult than it is with a full libc plus who knows what
all else already mapped into the address space, is also an important
difference.


> Now, if you want to talk about the security implications of shared 
> libraries (which, in this day and age, pretty much means "dynamic 
> loading"), let's use the case of a security fix being made available 
> for libc (or some other widely-used system library).

Oh, come on now Jason.  Do you really think that's anything more than a
fallacy these days, especially for NetBSD (or any open-source system)?

I.e. we're not running SunOS (or IRIX, etc.), we're running NetBSD for
goodness sake!  We have the source!

I threw that fallacy out with dirty bath water a long time ago and
without even bothering to look to see if the baby was still in the basin
(because I had a pretty good idea he wasn't :-), and what do you know
but he really was already sitting high and dry in a nice fresh warm
towel out of harm's way.

>  Sure is a lot 
> easier to update one file than it is to re-link all of your binaries, 
> isn't it?

No, in my experience it's not "a lot easier".  Really.  And I do in fact
have _lots_ of _relevant_ experience here with this very matter.

Even a wimpy old free-for-the-asking P-Pro 200 MHz machine can re-link
the whole system, X11 and all, in just a very few short hours, and
re-deploying all the binaries to production systems is not really any
more difficult or time-consuming than deploying one library file (if you
believe otherwise then you haven't measured the right things or measured
"difficulty" correctly), plus it has the advantage of ensuring all fixes
to all programs are installed all at once.  Some folks I work with
actually do "cvsup" or "cvs update" (tracking the stable branch)
followed by "make world" (they're FreeBSD users) on _all_ their machines
for _every_ update.  With a little planning one can even use that
session replicator tool to type the same commands into all machines at
the same time.

Rebuilding one library and re-deploying it is _NOT_ a "lot" easier than
rebuilding everything and re-deploying everything, and especially not
from a "complexity" perspective since the exact same (scriptable)
procedure always works for _everything_, every time, when the whole
system is rebuilt, or at least re-linked, and re-deployed.

I also just did a quick analysis of all the security advisories ever
issued for NetBSD, and guess what....  There appear to only have been
five that affected library code -- five out of 107, over 6 years.
That's not much added effort to patch static-linked systems -- almost
negligible, especially since all those flaws were not critical for all
systems.  I'm sure similar rates apply to other systems.  For example
even with all the many security patches to SunOS-4 over the years I only
remember having to re-build my custom libc.so (with the BIND-4 resolver
integrated to replace the original) a very few times (maybe only once?).

Relinking applications is admittedly a bit more difficult on slow
machines, especially given the way pgksrc works and is normally used
(assuming that it is being used), but a slightly deeper analysis of
those five library flaws reveals that quite a few were in specialized
libraries, such as libcrypto and libz which affect only a fraction of
applications that might be in use on a given platform.

Meanwhile one does not have to give up entirely on dynamic linking for
applications just to have a primarily static-linked, and thus highly
efficient, base system.  I still build and install the shared libraries,
and I still use some dynamic linked applications (though as few as
possible since I can analyze the threat of any given flaw and I have
fast enough machines to do the rebuilds if necessary)

You can have your cake and have eaten it too!

-- 
						Greg A. Woods

H:+1 416 218-0098  W:+1 416 489-5852 x122  VE3TCP  RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>          Secrets of the Weird <woods@weird.com>