[226] in bugtraq

home help back first fref pref prev next nref lref last post

Re: [8lgm]-Advisory-14.UNIX.SCO-prwarn.12-Nov-1994

daemon@ATHENA.MIT.EDU (Gene Spafford)
Mon Nov 28 13:41:49 1994

To: "Jonathan M. Bresler" <jmb@kryten.Atinc.COM>
Cc: Dave Brookshire <david@irc.umbc.edu>,
        "[8LGM] Security Team" <8lgm@bagpuss.demon.co.uk>, bugtraq@fc.net
In-Reply-To: Message from "Jonathan M. Bresler" <jmb@kryten.atinc.com>  of
    "Mon, 28 Nov 1994 09:36:42 -0500"
    <Pine.3.89.9411280921.C28006-0100000@kryten.atinc.com> 
Date: Mon, 28 Nov 1994 10:46:29 -0500
From: spaf@cs.purdue.edu (Gene Spafford)

> On Mon, 28 Nov 1994, Gene Spafford wrote:
> > 
> > > I think that the biggest pro of full disclosure, is that it get's people 
> > > off their butts and gets a good solution or patch that much faster.
> > 
> > I have yet to see evidence of this.  Based on my conversations with personnel 
> > at various computer companies, the only thing full disclosure seems to do is 
> > (sometimes) encourage them to release bug fixes without quite as much testing. 
> >  This sometimes leads to patches that don't completely fix the problem.  That 
> > is not a "good solution."
> 
> 	this is an excellent argument for using one of the free unix 
> systems.  the support team response time is much better.  if you have the 
> knowlege and ability, you can fix it yourself.  


Those "if" qualifications are quite a bit bigger than you may realize.
I regularly give tutorials to the people who run major computer
centers and they are now switching over to Unix.  They don't know C,
don't know Unix, and are responsible for getting the plant moved over
to Unix.  They aren't allowed to use freeware or shareware (insurance
and legal staff won't allow it) even if they knew how, which they
don't.  They often aren't on the net and don't plan to get Usenet
groups even if they do connect, so they have no contact with "support
team[s]" for free unix.

Then there are others, like myself, who are using hardware that is not
adequately supported by any free versions of Unix.  Or (again like
me), my software is supported by a paid staff and not by myself.  They
are using a commercial offering because it is consistent across about
10 different machine architectures in the department.

Actually, it is possible to get source to commercial versions of Unix,
if you think it is worth the expense.  Therefore, the argument doesn't
apply solely to "free" versions of Unix.  Large corporations with a
concern for security do pay for source licenses for precisely this
reason.  (Rhetorical question: I wonder how much of the "full
disclosure" pressure is from people using "free" versions of Unix who
hear about a bug and demand the details to know if it applies to their
systems?  They're getting what they [didn't] pay for, but are
agitating for more information at the potential expense of endangering
other users.)


If we are concerned about improving the state of computer security for
*everyone*, we need to give careful thought to the needs and abilities
of the entire use community -- not just the ones who are comfortable
with kernel hacking, free software, and the Internet.

On the other hand, if all we are concerned about is our own personal
security picture, then having sources is the way to go, assuming we
have time and talent to pursue them.  (But note how many people have
tried to program around the race condition in /bin/mail and gotten it
wrong -- including the pros inside Sun, and many people on this list
who had access to source code.)

I'm not trying to dispute your statement -- merely pointing out that
most people don't understand all the complexities of the situation
behind issues of disclosure and patches.  Or, they don't care, because
they only are concerned with getting fixes for themselves.

I'm also not trying to reopen the debate about full vs. partial vs. no
disclosure.  I'd like to see some hard evidence for things, though,
and *not* debate.  Even my experience has been anecdotal (but I
believe that it is more representative of the true user community than
these lists are).  Statements to the effect that "policy X produces
patches faster than policy Y" should be backed up by testable data.
Otherwise, they fall in the category of faith healing, diet aids, and
sightings of Elvis -- the observer may believe it is true, but there
is no controlled way to demonstrate it to skeptical observers in a
general setting.


Cheers,
--spaf
in his professor mode :-)

home help back first fref pref prev next nref lref last post