[236] in bugtraq
Re: [8lgm]-Advisory-14.UNIX.SCO-prwarn.12-Nov-1994 (fwd)
daemon@ATHENA.MIT.EDU (Jonathan M. Bresler)
Mon Nov 28 19:01:19 1994
Date: Mon, 28 Nov 1994 16:30:18 -0500 (EST)
From: "Jonathan M. Bresler" <jmb@kryten.Atinc.COM>
To: Gene Spafford <spaf@cs.purdue.edu>
Cc: Dave Brookshire <david@irc.umbc.edu>,
"[8LGM] Security Team" <8lgm@bagpuss.demon.co.uk>, bugtraq@fc.net
gene, i have a lot of respect for you and what you have done
(are sitll doing) for the user community. but i dont agree with
everything that you have said here.
On Mon, 28 Nov 1994, Gene Spafford wrote:
> > 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.
a corporation should hire or train people to do this work. if
they wont or cant, then that is their decision and they may have to live
with it. maybe not, they might not get found out and if they connect to
the net thru a strong firewall, they are better off than many. but its
the corporation's responsibilty to protect its assets as it sees fit.
they could also contract with cygnus or the like for support.
with the advent of betsi, free software from respectable
organizations like fsf is better than hardware from some (intel?). i
can understand intel's plight; but commercial == better is very often
untrue. how much better off would we be if hardware companies would
donate their os budgets to fsf? then we would have a free, well
supported unix that runs on most major platforms. this would have the
additional benefit of providing us with a standard unix which all
software vendors can write to. larry wall's configure code shows how bad
the situation is.
> 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.
more reasons for hardware vendors to fund fsf.
> 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.
if they are buying a source license, i hope they are buying the
expertise to read, and use the code.
> (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.)
FreeBSD is all 4.4BSD with parts from 386bsd, netbsd and linux.
(yes, fragmentation of effort is a problem. another reason for funding
fsf)
> 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.)
that's another reason we need the best individuals working on
this. i am not saying that i can get it right (everytime) but rather
that small groups of experienced people given the data can. these people
should be funded to do so. as independents, the vendor's reputation is
not at stake, neither is his development budget.
> 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.
i am not arguing for full disclosure and do not want to reopen an
endless mailfest. i am saying that the present situation is seriously
flawed and needs to be corrected. how? that's beyond me. i am doing a
little here to wean managment away from the the concept that only money
gets good software (vendors compilers are gcc bootstrap code?) by running
projects on FreeBSD hardware. the 486dx-66, FreeBSD 1.1.5.1 runs fft's
faster than our sparcserver 10/670MP, even with the MP unloaded. <cheap
shot, the MP runs twice the number of processes faster, but the same
process slower>
fwtk, logdaemon, skey, tripwire, cops are all other examples.
FreeBSD bugs are found and squashed before sun can even acknowledge a bug
exists. what can i say about hardware vendor's software? great binders?
fills my bookshelf nicely?
i wish i had good evidence, even any evidence, one way or the
other. all i have are observations of various corporations, trying, not
trying, suceeding, failing. i think we could reasonable expect better
performance from individuals that are dedicated to this work rather than
hardware corporations that include an os with their box
> Cheers,
> --spaf
> in his professor mode :-)
good mode. learned a lot from people in that mode.
Jonathan M. Bresler jmb@kryten.atinc.com | Analysis & Technology, Inc.
| 2341 Jeff Davis Hwy
play go. | Arlington, VA 22202
ride bike. hack FreeBSD.--ah the good life | 703-418-2800 x346
