[ On Monday, September 15, 2003 at 17:35:51 (-0400), Todd Vierling wrote: ]
> Subject: Re: BSD auth for NetBSD
>
> 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.

You really didn't pay attention to what I said.

The _benefit_ of static binaries is that the processes run from them
_cannot_ dynamically load new code.

The maintenance issues you speak of is completely separate and must be
balanced _against_ the benefit I speak of.

Sun is not an Open Source vendor, nor is M$ for that matter.  They have
_very_ different concerns for their operating systems than any open
source system has.

While _you_, or Sun, or even Wasabi Systems (and thus perhaps TNF as
well), may have to think about weighing the cost of relinking against
libc vs. the cost of allowing sensitive processes to load new and
potentially foreign code; _I_ do not have to worry about this issue.
For me the added cost of upgrading static linked systems is very
literally not measurably significant.  I already build static linked
systems and I can deploy a fix to libc to my customers with just as much
ease and speed as I could deploy one by way of an updated to a shared
library.  That is true even if I always assume that the affected object
code is used by _every_ system binary (which in practice is rarely true).

I have indeed seen all the hand-waving about how much easier it is to
install a single file or two vs. a whole set of files.  I know perhaps
better than anyone the issues related with identifying exactly those
binaries which contain object code derived from source containing a
known bug, especially in a unix development environment.  However it is
_because_ I understand all these issues in depth that I've chosen to
build static-linked systems, not in spite of them.

Meanwhile shared libraries have demonstrably created enormous
maintenance headaches for almost every non-security related issue
(witness the inability of NetBSD to bump the major number on libc and
the ongoing and ever increasing complication this causes for the
ever-changing API it tries to implement -- and that's just the tip of
the iceberg of problems for NetBSD, never mind the industry as a whole).
I don't know a single software engineer with any significant experience
who can even begin to say with a straight face that shared libraries
have made their jobs easier.  In fact several the software engineers I
know personally who have the most, and the most recognized and
respected, experience are highly critical of the kind of shared library
mechanisms employed by NetBSD.  Indeed these problems are not directly a
fault of dynamic linking alone, but they are tied to the way NetBSD
implements dynamic linking (and they are partly tied to the
implementation language too).  The fact is though that's all we've got
for now and so we either endure the problems, or stick our heads in the
sand, or where possible simply avoid using such flawed features.

> The only security problem with dynamic linking has been with programmer
> error

(Well, no, not exactly, but....)

As are many software security problems.  Your point is meaningless in
this context.  Finger pointing or saying that bugs must be fixed
regardless doesn't change the fact that bugs occur and the ability to
load new code remains a significant vulnerability.

The fact that we've only seen active exploits for dynamic loading bugs
in operating system kernels only relates to the relative benefit to the
attacker of choosing the kernel as a primary target.

> 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?

"Modular code" != "plugin code"  Please don't think you can pull such
obvious bait and switch attack and get away with it.  You have no point.
_Your_ argument on this point is the one chock full of red herrings.

> 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.

Well, it's not a cost that at least some OS users have been truly
willing to endure.  Even some NetBSD users (other than myself) have
learned that the performance benefits of static linking in cannot be
ignored.  Even some NetBSD users (other than myself) have come to
understand the upgrade headaches caused by the kind of dynamic libraries
NetBSD uses.

Thanks a great many economic and societal factors we no longer have to
worry anywhere near as much about the size of static-linked binaries.
Even a complete alpha build of NetBSD with '-g -static' isn't very large
in modern terms (I know -- I'm running one right now).

> 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?

Well, since I do build static-linked systems, and since the resulting
performance boost is often enough just as significant as the one Jason
achieved by re-instating an infamous and very poorly designed hack into
the system, I think you're being very hypocritical.  Do you really
expect anyone to fall for this?  Do you really think all NetBSD users
are so naive that you can pull this wool over their eyes?

-- 
						Greg A. Woods

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