Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU
Path: utzoo!decvax!bellcore!ulysses!ucbvax!apollo
From: apollo@ucbvax.UUCP
Newsgroups: mod.computers.apollo
Subject: Re: apollo access control
Message-ID: <8602210823.AA07149@uw-beaver.arpa>
Date: Thu, 20-Feb-86 17:31:47 EST
Article-I.D.: uw-beave.8602210823.AA07149
Posted: Thu Feb 20 17:31:47 1986
Date-Received: Sun, 23-Feb-86 01:48:00 EST
Sender: usenet@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 24
Approved: apollo@yale-comix.arpa

I'm no security expert, but I think that the problem of doing distributed
computing where the units of distribution don't trust each other is something
of an open research problem, and at the very least requires real-time
encryption of just about everything sent over the net, and authentication
server based access control.  I am not aware of any commercial vendors who
currently offer such a system.

Many of your complaints have to do with intra-node security.  Obviously,
anyone who has physical control over a machine can do whatever they want with
it.  This problem isn't unique to Apollo nodes.  How secure would you feel if
your malicious students were able to configure new kernels and reboot the Vax
that you do your work on?

I won't go into a lot of detail about so-called privileged ports, but I
think it is generally agreed in the industry that at best they only provide
the illusion of security, and at worst they encourage breaches of security,
as every server (and every programmer who develops server software) needs
to have superuser rights.

Security is a problem on any tightly coupled set of machines, but to single
out Apollo and imply that the problem is worse for us is bogus.  If it seems
worse for us, that's only because we do a better job than anyone else at
integrating our network.
-------