🚀 go-pugleaf

In article <eronald.726016050@ruble>, eronald@fml.tuwien.ac.at (Edmund Ronald) writes:
>  Several people remarked that virues on Unix machines were "impossible"
>because of the access control separating accounts. 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. In fact,
>if I may venture some sarcasm, if administrators and vendors did not make
>such exagerated claims about Unix security, then there would probably be
>fewer attacks :)

The main problem with Unix security is that there are a lot of holes to
plug. The system administrator can make a unix system fairly secure,
placing the weak point with the users, but you have to really be careful
about programs that run setuid, protections on all files, and other such
issues.

One may ask how easy it is to make a unix system secure, and I agree that
it is not easy to make a system that is used by a lot of users for various
sophisticated tasks secure. Additionally, unix being so widely distributed
and talked about has a hard time relying on "security through obscurity",
since any hole will get talked about. I do wonder how much more secure
other OS's are, where the ability to keep a security hole quiet is a bit
easier.

-- 
    Martin Terman, Mutant for Hire, Mean Ol' Top, Priest of Shub-Internet
    Disclaimer: Nobody else takes me seriously, why should you be the first?
mfterman@phoenix.princeton.edu mfterman@pucc.bitnet terman@pupgga.princeton.edu
"Sig quotes are like bumper stickers, only without the same sense of relevance"

eronald@fml.tuwien.ac.at (Edmund Ronald) writes:

>  Several people remarked that virues on Unix machines were "impossible"
>because of the access control separating accounts. [etc.]

Clearly UNIX viruses are possible, but are harder to do than in the MS-DOS
and Mac world.  As several others have noted, access control and memory
management make the job of the virus writer more difficult, but don't
eliminate the possibility.  But on to the main point...

>I was interested in FUTURE systems: How might these be rendered "resistant
> by design"?

The first step is to go back to the dreaded Orange Book...while it doesn't
have anything that talks about viruses, it DOES talk about designing and
developing secure systems.  The reason most systems are so vulnerable
to viruses, trojan horses, bugs, etc., is that they are not designed,
implemented, or tested in a rigorous fashion.  No matter what you're going
to do to avoid viruses, if you don't design and build the system in a
way to ensure that it's right (i.e., with high assurance) the bugs will
exist allowing clever and malicous users to bypass the security.

As to what *mechanisms* work, I'd suggest going back to a lot of work
done in the 60s on capability-based mechanisms, along with some newer
work to update it.  Unlike traditional access control which is based
on a user's identity (and perhaps other attributes), capabilities give
individual *programs*, or even parts of programs, the ability to access
objects (such as files) within the system.  A properly implemented
capability system should be relatively virus-resistant, since the virus
would not have any capabilities, even if the user executes it accidentally.
Of course, if the user can be tricked into assigning capabilities to the
virus, or the virus can obtain the capabilities through a bug in the
system, this doesn't help.

The problem with this approach, and the reason capabilities aren't used 
very much is that it's more complicated and less intuitive (IMHO) to
manage them.  To implement a UNIX-like interface on top of a capability
system every utility would have to be granted access to every possible
file.  That is, if I want to run "grep" on all my files, it's a real
nuisance to first have to invoke a trusted interface to grant grep
all the needed capabilities, and then to run the untrusted grep program.

Like Mr. Roland (the poster of the original question), I'd be interested
in other approaches people would propose.
-- 
Jeremy Epstein			Internet: epstein@trwacs.fp.trw.com
Trusted X Research Group	Voice: +1 703/803-4947
TRW Systems Division
Fairfax Virginia

eronald@fml.tuwien.ac.at (Edmund Ronald) writes:

>   Several people remarked that virues on Unix machines were "impossible"
> because of the access control separating accounts. 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. In fact,

Uh, you either missed my messages or have misunderstood them...
Viruses on Unix are by no means impossible - I have one of them here,
in front of me (it's a boring shell script infector), and in fact the
first scientific experiments with viruses were made in an Unix
environment... No, my paint was that in multi-user systems (Unix being
just an example) viruses do not spread well, because the sharing is
usually limited. Of course, if one of the privileged accounts gets
infected, then the virus spreads like wildfire...

> I was interested in FUTURE systems: How might these be rendered "resistant
>  by design"?

In general, there seems to be some hope in MAC systems with object
labeling and clear distinguishment between code and data. On such
systems only a few privileged programs (compilers, linkers) are
allowed to modify the executable objects and this right is not
transferable. Even this does not make viruses on such systems
impossible (because, a compiler that compiles itself is essentially a
virus; see Thompson's lecture on trusting trust), but such systems are
much more virus-resistent.

Regards,
Vesselin
-- 
Vesselin Vladimirov Bontchev          Virus Test Center, University of Hamburg
Tel.:+49-40-54715-224, Fax: +49-40-54715-226      Fachbereich Informatik - AGN
< PGP 2.1 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
e-mail: bontchev@fbihh.informatik.uni-hamburg.de    D-2000 Hamburg 54, Germany

In article <1993Jan3.023308.25376@Princeton.EDU> mfterman@phoenix.princeton.edu (Mutant for Hire) writes:
>... but you have to really be careful
>about programs that run setuid, protections on all files, and other such
>issues.
>
>... I do wonder how much more secure
>other OS's are, where the ability to keep a security hole quiet is a bit
>easier.

Tandam Guardian has 'progid' which is morally equivalent to setuid.
MVS has something like 'privileged libraries'. In fact, every operating
system has some form of privilege mechanism and this mechanism is subject
to the universal problem of incorrect administration.

There is no such thing as a 100%, completely secure system outside of
the one described in the FAQ (buried in concrete etc) so UNIX is as good
as (or as bad as) all the others that actually have security mechanisms
(MVS, Tandem Guardian, VMS etc). MS-DOS & Mac OS are another matter since
you don't even have file protection that's worth anything.
-- 
Jerry M. Carlin	(510) 823-2441 jmcarli@srv.pacbell.com
Alchemical Engineer and Virtual Realist

In article <1993Jan4.163918.11360@PacBell.COM> jmcarli@srv.PacBell.COM (Jerry M. Carlin) writes:
>In article <1993Jan3.023308.25376@Princeton.EDU> mfterman@phoenix.princeton.edu (Mutant for Hire) writes:
>>... but you have to really be careful
>>about programs that run setuid, protections on all files, and other such
>>issues.
>>
>>... I do wonder how much more secure
>>other OS's are, where the ability to keep a security hole quiet is a bit
>>easier.
>
>Tandam Guardian has 'progid' which is morally equivalent to setuid.
>MVS has something like 'privileged libraries'. In fact, every operating
>system has some form of privilege mechanism and this mechanism is subject
>to the universal problem of incorrect administration.

I believe the original point that was being made is that MacOS and MS-DOS
do not have any such mechanism.  Therefore, security on them is not possible,
or is limited entirely to the physical security of the machine.
--scott

In article <eronald.726016050@ruble> eronald@fml.tuwien.ac.at (Edmund Ronald) writes:
>  Several people remarked that virues on Unix machines were "impossible"
>because of the access control separating accounts.

Yes, and all these folks are just plain wrong.  Viruses are easy to
write for UNIX.  What's hard is (1) getting them to propagate, (2)
hiding them, and (3) making them do more than trivial things.  In
particular, (2) and (3) tend to be somewhat mutually exclusive.

See Tom Duff's "Viral Attacks on UNIX System Security" in the Winter
'89 USENIX Proceedings, and Doug McIlroy's "Virology 101" in the Spring
1989 issue of Computing Systems.  (Or buy a copy of my UNIX security
book, which has summaries of them both.  :-)

>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.

While this is a semi-true statement, it does not answer the claims
about viruses being "impossible" on UNIX.  Although there have been
numerous security problems discovered in UNIX in the last ten years,
*none* of them have been related to viruses.  (Sorry, Morris' little
excursion was not a virus.)  I would challenge you to cite a single
instance of a successful virus attack on UNIX outside of the
laboratory.

>In fact,
>if I may venture some sarcasm, if administrators and vendors did not make
>such exagerated claims about Unix security, then there would probably be
>fewer attacks :)

If I may venture some sarcasm in return, if people did not make such
irresponsible statements as, "UNIX security is an oxymoron," we might
not have so many newbie sys admins who don't even bother to read the
security section in their vendors' manuals, thinking the situation
hopeless.

UNIX security is *not* an oxymoron, and the careful sysadmin can do
some very simple things to make his system relatively difficult to
penetrate.  There are two good, comprehensive books on UNIX security
out there (Spafford/Garfinkel and Curry); buy one of them, *read* it,
and *do* what it says!

>PS. I personnally use a NeXT computer, a Unix box with a wysiwyg GUI built
>on top of a Display Postscript server that handles screen and keyboard, and
>mouse. Mail on these can contain embedded Postscript, which is executed at
>read-time by the server. Need I say more about how un-security can be buit
>into a system?

Yes, you need say more.  It should also be pointed out that this has
nothing to do with the UNIX-ness of the NeXT.  Put the same Display
PostScript and embedded-PS mail on an MS-DOS or Mac box, and you have
the same problem.  In fact, the problem is probably *worse* than on a
UNIX box, because of UNIX's file access permissions.

Dave Curry

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

In article <1iaek2INNm6l@uther.cs.purdue.edu>, spaf@cs.purdue.edu (Gene Spafford) writes:
> 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! 

Also netnews...