[HECnet] How much should you be allowed to shoot yourself in the foot?

[Thomas DeBellis]

I was updating some of MRC's late changes into my version of PANDA.  A 
(very) few of these were not documented with a change number, so I had 
been caught by surprise.  While doing this, I stumbled over some 
defensive coding that he had put in to keep even an enabled WHEEL or 
OPERATOR from doing something /Really/ /Bad/.

I got to wondering about this, which led me to think about the use of 
the OPERATOR id, which is analogous to the [1,2] PPN under Tops-10 and 
maybe having administrator rights under Windows, not as bad as root.

Tops-20, like most mainframe operating systems of the day, assumed a 
trained operations staff (as in trained to "DON'T TOUCH") and a trained 
systems programming staff.  However, this all-or-nothing approach 
eventually became more granular with the implementation of SEMI-OPR 
capability.  I had implemented this at Columbia several years earlier 
with SC%LOP, or Little Operator capability (this was known colloquially 
as l'opr.)  We had a number of training issues with our operators (some 
of them literally could not read), so this allowed them to use Galaxy to 
mount tapes and paper forms, but nothing more.  PANDA provides 
administrator capability (SC%ADM) which allows a certain amount of file 
system administration.

The PANDA access control job (ACJ) already puts certain restrictions on 
OPERATOR, mainly in the area of login.  It occurred to me that the above 
assumptions concerning training simply are not true in the current 
hobbyist universe.  You can actually remove OPERATOR (SC%OPR) capability 
from the OPERATOR id, which will break a rather large number of things.  
As a matter of fact, you can delete the OPERATOR id entirely.  I'm not 
sure you could complete boot up into an sensible state after that; I 
guess you'd need to turn on debugging and go directly to KDDT to then 
recreate the id by hand. That's training; maybe Monitor Internals level 
training...

And of course, even trained individuals can do dumb things... (GUILTY!)  
So I modified the ACJ further to implement the following policies on a 
CRDIR% of OPERATOR:

 1. May not delete OPERATOR.
 2. May not remove SC%OPR from OPERATOR.
 3. May not set OPERATOR not login-able
      * FILES-ONLY
      * INVALID
      * CHARGE-LIMITED
 4. May not set OPERATOR FTP-ONLY (no way to get to the EXEC; the normal
    time-sharing user interface)
 5. May not set 'junk' (I.E., undocumented) bits in OPERATOR directory
    protection word
 6. May not set OPERATOR directory protection to allow world read, write
    or connect
 7. May not clear the OPERATOR password (set to NUL)

If you're winning enough to defeat these restrictions, then maybe you're 
winning enough to understand the ramifications of doing them.

Comments for other DEC OS's?  I don't remember what RSTS, RSX and VMS do.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sonic.net/pipermail/hecnet-list/attachments/20201012/8e727b0f/attachment.html>