Re: a point is being missed

[strombrg () hydra acs uci edu (Dan Stromberg - OAC-DCS)]

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