Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!OCDIS01.AF.MIL!robjohn
From: robjohn@OCDIS01.AF.MIL (Robert Johnson (CDC Contractor);CDC;)
Newsgroups: comp.protocols.tcp-ip
Subject: re: toll restrictors
Message-ID: <9005311822.AA14512@ocdis01.af.mil>
Date: 30 May 90 16:52:04 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 32

In response to my recent posting about using a software product rather
than a toll restrictor to control outbound connectivity, Andrew Heybey writes:

> I'm curious as to what you mean by "turn off telnet".  Of course, I don't 
> know what sort of system you're running and what sort of capabilities it 
> provides, but on a unix system, telnet is a user program that opens a 
> socket.  If you remove the telnet program, all I have to do to get that 
> capability back is get the source to a telnet program from somewhere and 
> compile it in my home directory.  Voila, I can telnet anywhere I want to.  
> I can do the same with ftp (in fact, I would write a crude ftp first so as 
> to be able to go get a better ftp and telnet from someplace else).  Does 
> your system not allow unprivilidged users to open network connections?  Are 
> you relying on nobody knowing how to write/compile/etc their own program to 
> use the net?  Or does your system have some other mechanism for controlling 
> network access?

Good question - nothing's ever as simple as it sounds, is it?  By 'turn off',
I mean we change permissions so only a trusted group of individuals can use
it - not the user population at large.  We protect telnet, ftp, cu, tip, and
the compilers and debuggers this way.  We also have daily reports showing who
is using these functions.  Rather than digress into a diatribe about system 
administration, I'll just say that our philosophy is not to deny service to 
our users, but to be fully accountable.  Certain users need to use these 
compilers, debuggers and communications (other than we have provided by menu 
access) for valid purposes.  We allow them to use them, but they must prove 
a valid need.  And, they know that we regularly monitor these activities.  
Running the system this way provides full functionality for all users (based 
on a valid need), and yet maintains full accountability of our connectivity 
with other systems.

Bob Johnson, System Administrator
Tinker Air Force Base, Oklahoma