On Wed, 11 Dec 2002, Greg A. Woods wrote:

# Code sharing can only be done _really_ securely in the unix environment
# by sharing the source code, not by sharing the object code.  To really
# make secure binaries you have to provide 100% of their object code in
# their executable image files so that the only other software that's
# involved in loading and running them is the kernel itself.
#
# (if memory use of shared code is really that much of a problem then
# there are other more secure ways to deal with it....)

ISTR this being the original motivation for shared-text (forgive me if I
have chosen the incorrect nomenclature).  The next logical
step would be for registry-on-exec of the text pages
from the program in question, such that things bound from static
libraries would remain in the cache for other programs to use (assuming
they were all linked with the same copy of the library to begin with).

Such a scheme, seems to me, however, more potentially fraught with bugs
than the current dynamically-loaded libraries, and certainly less
elegant.

I have a distinct problem with the concept that dynamic loading is
enough of a security risk to pose serious problems, and to hear on
the other hand that "there are more secure ways to deal with it"...
well, frankly, I'm waiting for the demonstration.  Bring it on.

I'm not convinced at all that only source code is shareable in a
secure manner.

By the same sword, I'm not convinced at all that dynamic loading
doesn't reduce the robustness of the system in question.

Depending on your point of view you can now evaluate UNIces to be
win-win or lose-lose situations.  Which do you choose, resource
conservation at the expense of performance and "security", or
vice versa?

I don't see either side as a particularly good situation.  I don't care
how cheap disk and memory are - the results just are not justified in
their waste.

				--*greywolf;
--
NetBSD: If you look through Windows