From: spaf@cs.purdue.edu (Gene Spafford)
Newsgroups: comp.security.misc
Subject: Re: Future OS virus immunity.
Date: 4 Jan 1993 17:44:18 -0500
Organization: Department of Computer Sciences, Purdue University
Distribution: world
	<1993Jan4.211207.25806@noose.ecn.purdue.edu>
NNTP-Posting-Host: uther.cs.purdue.edu
In-reply-to: davy@harbor.ecn.purdue.edu's message of Mon, 4 Jan 1993 21:12:07 GMT

I'll second Dave's comments.  Not because he posts from Purdue.  Not
because cited my book in addition to his own fine work. :-)  I agree
because he's basically right on both counts.

First, viruses that work under Unix are probably easier to write than
under other languages because of the higher-level scripting languages.
I've experimented with ksh and perl versions...both of which would
work better under DOS or any other system with those utilities, but
certainly under Unix.

If you take Fred Cohen's definition of virus, then Unix itself is one
of the most successful viruses ever written, since it tends to result
in the creation of modified versions of itself on other computer
systems! 

However, other than the puckish comments one might make about the
damage Unix has wrought, there really do not seem to be any actual
cases of damage being caused by real viruses under Unix.  

If you look at the nature of viruses, they require:
  1) Writeable areas of storage that are then rexecuted in some manner
  2) Sharing of that storage between users
  3) Some form of sharing between systems

A system with proper file permissions is unlikely to have #1 hold.  In
fact, if a system admin were to put all system binaries on read-only
media as many of us recommend, then all a virus could do is infect a
single user's files and not spread to system files even if root was
compromised. 

The fact that cautious Unix users are reluctant to share binaries from
machine to machine helps ensure that new viruses are unlikely to
spread in that form.  They would need to be in source code or some
interpreter code (like Perl or Lisp).  That certainly is possible (how
many people read the code that comes with GNU Emacs before installing
it?), but unlikely to go without detection before long.

And, as far as detection goes, that's why Gene Kim and I put
"Tripwire" together. :-)


I really do agree with Dave's comment about denigrating Unix security.
Yeah, there are weaknesses.  However, many (most?) of the *real*
security problems are simple ones, and some education and care will go
a long ways towards making things better.  If enough people said "If
you get in a traffic accident with a truck, there is nothing you can
do to save yourself," then maybe some people would stop using
seatbelts or driving defensively.  That would be a pity, because that
does help precent most accidents and mitigate loss if one does happen.
The same with Unix security -- some simple precautions would help
prevent the majority of problems people have now, and others will help
reduce losses.

Edmund Roland:
>No one bothered to 
>remember that the past ten years have proven Unix system security to be an
>oxymoron, a topic that keeps graduate students entertained nights.

Yes, but those 10 years didn't see the same operational environment,
the same level of threat, the same network connectivity, nor the same
level of widespread use.  I'd be hesitant to draw sweeping conclusions
from the last 10 years -- things have changed a lot.  Heck, 10 years
ago there were under 2000 Usenet sites and I almost could read every
posted article each day with time left over to do real work, the
workstation was just really coming to market, and I don't think domain
names had yet caught on.  Trying to take the changes between then and
now can lead us only to say that lots of things can change rather
radically when the market demands.

Once the market demands better security tools, interfaces, and
defaults, it will happen.  Right now, however, people are making more
noise about GUI, transaction processing, and relational databases.
Security may well be next on the list....unless people get convinced
it is a hopeless task.



-- 
Gene Spafford
Software Engineering Research Center & Dept. of Computer Sciences
Purdue University, W. Lafayette IN 47907-1398
Internet:  spaf@cs.purdue.edu	phone:  (317) 494-7825
Newsgroups: comp.security.misc