Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!uunet!olivea!mintaka!bloom-picayune.mit.edu!athena.mit.edu!jik
From: jik@athena.mit.edu (Jonathan I. Kamens)
Newsgroups: comp.unix.admin
Subject: Re: Project Athena ( was Re: Non Destructive Version of rm)
Message-ID: <1991May9.201346.28483@athena.mit.edu>
Date: 9 May 91 20:13:46 GMT
References: <12049@mentor.cc.purdue.edu> <1991May8.174603.26309@athena.mit.edu> <12067@mentor.cc.purdue.edu> <1991May9.001907.13024@athena.mit.edu> <12112@mentor.cc.purdue.edu>
Sender: news@athena.mit.edu (News system)
Distribution: na
Organization: Massachusetts Institute of Technology
Lines: 65


  (I am omitting responses to points which have already been dealt with in
previous postings.)

In article <12112@mentor.cc.purdue.edu>, asg@sage.cc.purdue.edu (The Grand Master) writes:
|> I understand this. But if you only trust computers that won't be broken into,
|> then you are safer. What would happen if someone broke into one of your 
|> servers. Could they not delete all the files on all the filesystems for which
|> that machine is the server?

  What would happen if someone broke into one of your Symmetries?  Could they
not delete all of the files on all the filesystems for which that machine is
the server?

  Project Athena's service machines (e.g. file servers, authentication
servers, mail servers, etc.) are secured just as your machines are.

|> }  Security that depends on the good graces of every admin on your network is
|> }no security at all.  Furthermore, it DOES NOT SCALE.  The more machines you
|> }have on a network, the more people you need to run them, and the more people
|> }there are running them, the more possibility there is that someone will start
|> }playing around with root access.  Kerberos avoids this problem.
|> 
|> There still must be SOME people that have a top level of access. What is
|> to stop them from doing whatever they want?

  There are less than five people at Project Athena with access to the
authentication server.  That number can stay constant no matter how many
machines are added to our network.  The number of admins of individual systems
may grow as systems are added, but that does not decrease our security since
we do not trust those individual systems.

  On the other hand, the setup you are advocating trusts systems that are
added.  That means that every admin is trusted.  How many people have root
access to any of your machines, Bruce?

  There must always be some level of trust, because you've got to have someone
running things.  The point is to minimize the amount of trust required.  As I
said, trusting every admin does not scale, while trusting a very small,
constant number of people no matter what the size of the network does.

|>   But Jon conveniently failed to respond to my major gripe with
|> distributed computing. Resources go unused more often. 

  The paper I referenced in my last point addresses this "major gripe," which
is why I referenced it.  Did you bother to read it?  It's only a few pages
long.

|> If I am doing something CPU intensive on a workstation, I gain no
|> added benifit from the fact that only 1/10 of the workstations 
|> are in use. I also will see a significant reduction in the speed of
|> my window operations, since the same CPU is handling them and the
|> intensive task.

  If you are doing something so CPU intensive that your workstation slows
down, then either (a) get a better workstation, or (b) use a compute server
such as a Cray or DEC 9000.  As I pointed out in a previous posting, Project
Athena users *do* have access to those resources if they need them, which
means that we have the best of both worlds.

-- 
Jonathan Kamens			              USnail:
MIT Project Athena				11 Ashford Terrace
jik@Athena.MIT.EDU				Allston, MA  02134
Office: 617-253-8085			      Home: 617-782-0710