[2387] in bugtraq
Re: a point is being missed
daemon@ATHENA.MIT.EDU (Dan Stromberg - OAC-DCS)
Thu Nov 9 23:32:54 1995
Date: Thu, 9 Nov 1995 10:18:51 -0800
Reply-To: Bugtraq List <BUGTRAQ@CRIMELAB.COM>
From: Dan Stromberg - OAC-DCS <strombrg@hydra.acs.uci.edu>
X-To: BUGTRAQ@CRIMELAB.COM
To: Multiple recipients of list BUGTRAQ <BUGTRAQ@CRIMELAB.COM>
In-Reply-To: Your message of "Wed, 08 Nov 1995 12:00:47 EST."
<Pine.SUN.3.91.951108113052.18979K-100000@di2>
In message <Pine.SUN.3.91.951108113052.18979K-100000@di2>you write:
>On Mon, 6 Nov 1995, Casper Dik wrote:
>
>> 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).
>
>Unfortunatly, it is attitudes like this that will prevent Solaris from
>ever being able to statically link binaries. This attitude seems to be
>prevelant among all my contacts with Sun.
Casper knows you can link things statically on solaris - I learned
about it from him.
I can mail you stubs if you want them. It's not a large chunk of
code. You could construct one yourself from the manual page.
>> 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.
>
>Dynamic linking adds exposure to another aspect of your system. Leave
>the libraries open for attack through a program that has to run setuid
>or setgid and they will be attacked. Maybe not now, but they will be.
"chmod 666" would appear to be a good start.
>> First of all: all authentication programs are extensible through dynamic
>> linking, all localized programs are extensible through dynamic linking,
>> etc. Dynamic linking is required.
>
>"Extensible through dynamic linking"? How so? Please explain? What
>are we going to do, leave it dynamic so login user can add their own
>options on the fly? Sounds real secure to me!
As new naming services are added, old programs do not need to be
relinked to take advantage of them.
>> >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.
>
>Gee... then why hasn't Sun done something about sendmail so we can get
>off the sendmail advisory of the month club??
They have, in solaris 2.5. It's V8 now.
I add V8.7.1 into all my installs, via autoinstall, tho. 'no need to
follow the sendmail patches, and we get consistent sendmail across
platforms, that way...
>> In Solaris 2.6, what would you rather have: a statically linked login or
>> a totally dynamically configurable login?
>
>Sun, or anyone else, can make login configurable with a statically
>linked program. Having something configurable is NOT does not mean
>having to be dynamically linked!
>
>Besides, what kind of configuration options do you need? There are
>parameters in /etc/default/login that pretty much covers everything
>(with some exceptions I think would be worth looking into). Do you need
>a dynamic library to process that file? I don't think so!
Do you need static linking for security? I think that's the important
question.
It seems as tho dynamic linking would facilitate distribution of
patches, possibly minimizing patch interaction (if one thing is done
in one place, and not N places across the system).
Dan Stromberg - OAC/DCS strombrg@uci.edu
