Path: utzoo!attcan!uunet!pyrdc!pyrnj!rutgers!mailrus!umich!pha
From: pha@zippy.eecs.umich.edu (Paul Anderson)
Newsgroups: comp.sys.apollo
Subject: Re: some questions for the gurus.
Message-ID: <1152@zippy.eecs.umich.edu>
Date: 14 Sep 88 16:27:42 GMT
References: <8809081356.AA00196@caen.engin.umich.edu> <3e720dde.13422@apollo.COM>
Sender: news@zippy.eecs.umich.edu
Reply-To: pha@zippy.eecs.umich.edu (Paul Anderson)
Organization: University of Michigan EECS Dept. Ann Arbor
Lines: 69
UUCP-Path: ihnp4!umich!zippy!pha

In article <3e720dde.13422@apollo.COM> mishkin@apollo.com (Nathaniel Mishkin) writes:
>In article <8809081356.AA00196@caen.engin.umich.edu> frank@CAEN.ENGIN.UMICH.EDU (Randy Frank) writes:
>>It's always fun when flames start up on a list...
>
>Seemed like the fire was going out so I guess I'll have to give the embers
>a nudge...
>
>>I fundamentally disagree with those who state that security is a binary issue: if
>>you can't have perfect security, then why have any at all is b.s.
>
>
>But back to the particular problems raised in this discussion:  the
>signalling of processes you don't own and the shutting down of nodes.
>As Jim Rees said, the signalling issue is fixed in sr10 so that you have
>to be root or the same ID as the target process to be able to signal
>it.  As far as shutdown goes, Jim said something like "You can just turn
>the power off so what good does it do to require special privileges to
>execute the DM's SHUT command." The counters to that seemed to be "But
>look at the problems caused if you let randoms shut down nodes", which
>misses the mark.  Of *course* it can cause problems, but the fact of
>the matter is that the node is sitting on someone's desk and if he *wants*
>to cause problems, he'll just shut the power off -- he doesn't need to
>be able to issue the SHUT command.  If the retort here is "We have stupid

You are missing the point.  At CAEN (~430 apollos), we don't put network wide services
on student or private faculty nodes - we put them on dedicated fileservers,
dedicated gateways, dedicated mail machines, and others.  We can't afford
to have holes in not only all the student machines, but also in critical
network service machines, too.

Face it, and believe me, you must, a network can't exist for long
unless critical nodes CAN HAVE PROTECTION NOT CURRENTLY SUPPLIED BY
APOLLO.  Yes, it is true that most other machines have security problems
as well, but there is no excuse for using YOUR argument to leave
gaping holes in the system that prevent us from running a tight
ship.

We generally don't leave our critical nodes in physical contact with
general users.  We do this for a variety of reasons, including the
need to supply clean, regulated power, clean, cool air, central
sites for maintenance and backup, and others as well.  Yet, despite
this isolation, there are literally hundreds of ways for users
to hose central services provided by us.  Since some of our servers can represent
tremendous time and money investments, it is NEVER, NEVER a waste
of time for Apollo to allow for tightened security on their
network.

>users that might *accidently* issue the SHUT command", well, all I can
>say is if enough people think that's a real problem, shout now and I'm
>sure we'll do something about it.

We're shouting...

>
>-- 
>                    -- Nat Mishkin
>                       Apollo Computer Inc., Chelmsford, MA
>                       mishkin@apollo.com

I invite anybody at Apollo who wonders why we complain about
Apollo security, and software stability in general, to call
me at (313)-936-1355.

So that anyone doesn't flame me too badly, I have always thought that
Apollos are the best workstation ever built, bar none, but that
doesn't mean there isn't *lots* of room for improvement.

Paul Anderson
CAEN