Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!pasteur!ucbvax!ICAEN.UIOWA.EDU!dbfunk
From: dbfunk@ICAEN.UIOWA.EDU (David B. Funk)
Newsgroups: comp.sys.apollo
Subject: Re: some questions for the gurus.
Message-ID: <8809142353.AA14291@umaxc.weeg.uiowa.edu>
Date: 14 Sep 88 23:50:53 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 46

I would like to add my 2 cents worth to the security issue discussion.
Like Randy Frank and Paul Anderson, I administer Apollos in a university
environment. This environment is unusual in many ways: a wide range of
users (total novice to total hacker), a wide range of sites (private
nodes on faculty desks to public nodes in student labs), and a wide
range of work loads (dedicated file servers to nodes that must support
many types of uses). At our site we have nodes in buildings spread over
a mile of campus (we have 2 miles of cable in one building alone).
We have a staff of only a few people and when anything goes wrong
we are called out to fix it.
In this context there are at least 2 different types of security issues.
There is the classical problem of the "hacker attack" and then there is
the problem of casual or unintentional user created havoc.
   In article <3e720b36.c6f9@apollo.COM>, Nat Mishkin
(mishkin%apollo.uucp@eddie.mit.edu) talks about the "hacker attack"
problem. I agree, any time you have a "real" network connection to an
external public network, you have an almost impossible security problem
on your hands. Then you have to decide what level of risk and paranoia
you are willing to live with and then pay for it.
    The other issue is the one that has caused me the most problems.
Here are some examples of this: a user mistypes "ex" instead of "ed"
at the DM command window; a new user reads the "commands.hlp", sees
the 'shut' command and decides to try it, not believing that it will
actually do what it says that it will; a Unix user, frusterated by the
system's not doing what he expects, decides to kill off some of those
strange jobs that don't make sense to him like '/sys/spm/spm' and
'/sys/mbx/mbx_helper'; We have one node with a Danford SEU board,
when 8 students are logged in on it the probability of one killing
the wrong process is definitly greater than zero. All of these
have happened here and I could go on adnauseam in this vein.
    The point is that one malicious hacker could cause immense
amounts of damage but the little dumb things are actually our major
time killers. We went so far as to create 'patches' for sigp &
kill that force them to respect process ownership. These have
helped but I havn't been able to deal with "ex" and "shut".
I think that these are the kind of things that Randy Frank had
in mind when he wrote "we've lived with vanilla BSD Unix security
for years and it's been OK".
    I am pleased to see that SR10 will provide process ownership
and "crp" control. I would like to add my vote to the "shut" control
demand.

    Dave Funk
    Iowa Computer Aided Engineering Network (ICAEN)
    University of Iowa, Iowa City, IA
    dbfunk@icaen.uiowa.edu