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!ittatc!dcdwest!sdcsvax!ucbvax!apollo
From: JW-Peterson@UTAH-20.ARPA (John W Peterson)
Newsgroups: mod.computers.apollo
Subject: Re: apollo access control
Message-ID: <12184258328.14.JW-PETERSON@UTAH-20.ARPA>
Date: Tue, 18-Feb-86 01:09:59 EST
Article-I.D.: UTAH-20.12184258328.14.JW-PETERSON
Posted: Tue Feb 18 01:09:59 1986
Date-Received: Wed, 19-Feb-86 23:31:01 EST
References: <8602160516.AA08866@Yale-Bulldog.YALE.ARPA>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 68
Approved: apollo@yale-comix.arpa

Geez - and I thought some of our staff were hopelessly paranoid...

> I) TCP/IP is hazardous.
>         1) Apollo's do not seem to enforce the priveleged socket aspects of
>            Unix bsd4.2  TCP/IP. 
>         2) Since anyone can bind to such a socket  inbound use is virtually
>            insane...

It is generally acknowledged that BSD's "priviledged ports" are a pretty
flimsy security mechinism.  All it takes is any non unix box to walk right
through that door.  For example, anybody with an IBM PC and an ethernet card
can punch holes through this with little trouble.  

> However the pads
> can control the display manager so they can TYPE ON MY TERMINAL
> if they want.  I DON'T  WAN'T ANYONE ELSE TYPING ON MY TERMINAL.
>   ....
>  ...anyone can signal[/debug] anyones process, even across the net and 
> bridges.

This is only true if you run the server process manager (SPM) that allows
people to create arbitrary processes on your node.  If you're that terrified
about people invading your environment, don't run the SPM.  It certainly
isn't required on nodes with displays (although here we find it useful for
situations like graphics programs that run amuck - it's much easier to
CRP on and kill it remotely than to wait for the DM to finally time out).

>       3) Apollo has a trojan horse locksmith account build into login
> with account '<><><><>' and password unknown.  Why should they?

This login mechinism is only enabled when the node can't see the network
registries, and was undoubtedly created for debugging the login mechinism
(Haven't you ever locked your keys in the car?)

>       4) Why should copies of setuid and subsystem programs retain their
> priveleges, especially copies on floppy diskette, what would stop
> someone from changing the appropriate bits on a diskette and
> screwing with my system, or more easily just getting on his system
> and creating a setuid or subsystem manager and importing it
> to my system to wreack havoc?  

Again, if you're this paranoid you'd better lock up your tape/floppy drives.
Almost every system I've used (including Unix) can be easily compromised by
mounting bogus filesystems or plowing through the tape library.  Even with
the access to the media it would still be fairly tricky to use this to
break security under Aegis.  For example, in order to set a priviledged 
subsystem ACL (from a tape or by hand) you must have rights to that 
subsystem in the first place.  Also, it isn't enough for somebody to sit
down and create his/her own "login" subsystem.  Even if the subsystem has
the same name, it won't have the same UID - and that is what the system 
cares about.  

> Also by what bogus method has Apollo implemented setuid programs,
> since program/process management is done mostly by a user library
> which load programs in user mode( non-privleged) it is bound to
> be insecure and may present a means for programs changing ids.

A program under Aegis must fork or start a new process to change it's
associated user ID.  At this level the process management is done by the
kernel, not in user space.  The DM is a special case (analogous to init)
however, the bootshell is very specific about the programs it allows to
run in this position (i.e., only the DM, the SPM or login).

In general, it amuses me quite a bit that you seem to find Unix the model
of system security while not trusting something that is quite a bit more
sophisticated (Or perhaps you've forgotten the 4.2 sendmail bug already?).

-------