Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!randvax!segue!jim
From: jim@segue.segue.com (Jim Balter)
Newsgroups: comp.unix.wizards
Subject: Re: BSD tty security
Message-ID: <7612@segue.segue.com>
Date: 18 May 91 09:08:04 GMT
References: <26871@adm.brl.mil> <1991May13.223942.21459@jato.jpl.nasa.gov>
Reply-To: jim@segue.segue.com (Jim Balter)
Organization: Segue Software, Inc. - Santa Monica, CA. +1-213-453-2161
Lines: 72

In article <1991May13.223942.21459@jato.jpl.nasa.gov> dave@jato.jpl.nasa.gov writes:
>It is useful indeed. My point (and I don't know who else agrees with
>me) is that not only is this code needed to assert the validity of
>any said fixes,

As Dijkstra has pointed out, testing can only demonstrate the presense of bugs,
not their absense.

>but the code (or pseudo code) is needed to understand
>the hole.

Since you haven't seen it, how do you know?  In fact, since there are people
who understand the holes but haven't seen the break code, your statement is
counterfactual.

>A logical case can be made for security holes to be exposed;
>good security is not based upon obscurity.  

The holes have been exposed.  You may disagree, but that gives you no
justification for slinging personal attacks (not that you did in this note;
a welcome change from your previous ad hominem postings).

>Do you trust someone who doesn't trust you? Please answer honestly,
>now. Personally, and professionally, I do not.  

In _The Hunting of the Snark_, "the bowsprit got mixed with the rudder
sometimes", because the Bellman decided that, if no one was to speak to the
Helmsman, then the Helmsman was to speak to no one.  Your statement makes about
as much sense.  Very few people who don't trust me distrust me *personally*
(perhaps it is different for you).  When someone locks the door, it is because
they know there are thieves, not because they expect me personally to steal
something.  I have no more reason to distrust people who lock doors than people
who don't.  In fact, people who don't are careless and are less to be trusted.
Trust is an operational issue more than a moral issue.

>I find it extremely difficult to trust someone else's fixes when they
>not only distrust me,

This is like people who think there shouldn't be speed limits because they
don't speed and feel insulted by the presense of the laws.  Their problem is
egocentrism and an underdeveloped abstractual facility.  If there is reason to
think that there is anyone who is untrustworthy, then only those *known* to be
trustworthy will be trusted.  If you don't understand this concept, get a logic
text and look up "free variable".

>but I have little or no understanding of exactly
>what needs to be fixed and why. 

When you get the upgrade from your vendor, are you really going to demand the
source and its history so that you can understand exactly what was fixed and
why?  If we all demanded to know exactly how everything around us works and
why, we wouldn't get anything done.  It is far better to give people specific
tasks and to put QC and QA mechanisms in place than to try to do everything
ourselves.

>>(for at least a significant set of machines).  If you can not work
>>from his plan, you will not be able to anything more with the details
>>except exploit the bug!
>
>I disagree completely. If you have the details, you can eventually
>provide fixes...assuming competance. 

Assuming competence is assuming a lot, here.  Anyway, the details are in the
system code and in the design concepts that have been discussed, not in the
code that demonstrates a problem.  This whole concept of "providing fixes"
rather than doing design has a lot to do with the current cost of software
technology.

>    He who has self-conceit in his head - 
>         Do not imagine that he will ever hear the truth.

Indeed.