Google
 

Trailing-Edge - PDP-10 Archives - BB-KL11M-BM_1990 - t20src/acjfun.mem
There are 9 other files named acjfun.mem in the archive. Click here to see a list.

















                                  TOPS-20

                         FUNCTIONAL SPECIFICATION

                                    for

                     Enhanced Access Control Facility





                             Gregory A. Scott
                         LSBU Software Engineering

                            Created: 30 Nov 88
                         Last Revision: 17 Aug 89




     COPYRIGHT  (c)  DIGITAL  EQUIPMENT  CORPORATION  1989.    ALL   RIGHTS
     RESERVED.

     THIS SOFTWARE IS FURNISHED UNDER A LICENSE AND MAY BE USED AND  COPIED
     ONLY  IN  ACCORDANCE  WITH  THE  TERMS  OF  SUCH  LICENSE AND WITH THE
     INCLUSION OF THE ABOVE COPYRIGHT NOTICE.  THIS SOFTWARE OR  ANY  OTHER
     COPIES  THEREOF MAY NOT BE PROVIDED OR OTHERWISE MADE AVAILABLE TO ANY
     OTHER PERSON.  NO TITLE TO AND OWNERSHIP OF  THE  SOFTWARE  IS  HEREBY
     TRANSFERRED.

     THE INFORMATION IN THIS SOFTWARE IS SUBJECT TO CHANGE  WITHOUT  NOTICE
     AND  SHOULD  NOT  BE  CONSTRUED  AS  A COMMITMENT BY DIGITAL EQUIPMENT
     CORPORATION.

     DIGITAL ASSUMES NO RESPONSIBILITY FOR THE USE OR  RELIABILITY  OF  ITS
     SOFTWARE ON EQUIPMENT THAT IS NOT SUPPLIED BY DIGITAL.
Enhanced Access Control Facility Functional Specification            Page 2


                             TABLE OF CONTENTS


        1.0     Summary of Functional Change . . . . . . . . . . . . 3
        1.1       Changes from 7(130) to 7(131)  . . . . . . . . . . 3
        1.2       Changes from 7(105) to 7(130)  . . . . . . . . . . 3
        1.3       Problem Discussion and History . . . . . . . . . . 4
        1.4       Description and Goals  . . . . . . . . . . . . . . 4
        1.5       Limitations and Restrictions . . . . . . . . . . . 5
        1.6       Supporting Information . . . . . . . . . . . . . . 5
        1.7       Security Consciousness . . . . . . . . . . . . . . 5
        2.0     Terminology  . . . . . . . . . . . . . . . . . . . . 7
        3.0     Architectural Position . . . . . . . . . . . . . . . 7
        3.1       Access Control Profile Generation  . . . . . . . . 8
        3.2       Access Control Facility Operation  . . . . . . . . 8
        3.3       Program Organization . . . . . . . . . . . . . . . 9
        4.0     Related Documents and Standards  . . . . . . . . . . 9
        5.0     Services Provided  . . . . . . . . . . . . . . . . . 9
        5.1       Access Control Profile . . . . . . . . . . . . . . 9
        5.1.1     Disable Command  . . . . . . . . . . . . . . . . . 9
        5.1.2     Enable Command . . . . . . . . . . . . . . . . .  11
        5.1.3     Help Command . . . . . . . . . . . . . . . . . .  12
        5.1.4     Save Command . . . . . . . . . . . . . . . . . .  13
        5.1.5     Set Command  . . . . . . . . . . . . . . . . . .  13
        5.1.6     Show Command . . . . . . . . . . . . . . . . . .  14
        5.1.7     Take Command . . . . . . . . . . . . . . . . . .  14
        5.1.8     User Command . . . . . . . . . . . . . . . . . .  14
        5.1.9     Write Command  . . . . . . . . . . . . . . . . .  16
        5.2       Access Control Policy  . . . . . . . . . . . . .  16
        5.2.1     Access (.GOACC)  . . . . . . . . . . . . . . . .  16
        5.2.2     Arpanet Access (.GOANA)  . . . . . . . . . . . .  17
        5.2.3     Assign Device (.GOASD) . . . . . . . . . . . . .  17
        5.2.4     Assign Due To OPENF% (.GOOAD)  . . . . . . . . .  17
        5.2.5     Attach Job (.GOATJ)  . . . . . . . . . . . . . .  18
        5.2.6     Capabilities (.GOCAP)  . . . . . . . . . . . . .  18
        5.2.7     Class Assignment (.GOCLS)  . . . . . . . . . . .  18
        5.2.8     Class Set At Login (.GOCL0)  . . . . . . . . . .  19
        5.2.9     Create Directory (.GOCRD)  . . . . . . . . . . .  19
        5.2.10    Create Fork (.GOCFK) . . . . . . . . . . . . . .  19
        5.2.11    Create Job (.GOCJB)  . . . . . . . . . . . . . .  20
        5.2.12    Create Logical Name (.GOCRL) . . . . . . . . . .  20
        5.2.13    CTERM Connection (.GOCTM)  . . . . . . . . . . .  20
        5.2.14    DECnet Access (.GODNA) . . . . . . . . . . . . .  20
        5.2.15    Detach (.GODTC)  . . . . . . . . . . . . . . . .  20
        5.2.16    ENQ Quota Set (.GOENQ) . . . . . . . . . . . . .  21
        5.2.17    Get Directory (.GOGTD) . . . . . . . . . . . . .  21
        5.2.18    GETAB% JSYS (.GOGTB) . . . . . . . . . . . . . .  21
        5.2.19    HSYS% JSYS (.GOHSY)  . . . . . . . . . . . . . .  21
        5.2.20    INFO% JSYS (.GOINF)  . . . . . . . . . . . . . .  21
        5.2.21    LATOP% JSYS (.GOLAT) . . . . . . . . . . . . . .  22
        5.2.22    Login (.GOLOG) . . . . . . . . . . . . . . . . .  22
        5.2.23    Logout (.GOLGO)  . . . . . . . . . . . . . . . .  22
        5.2.24    MDDT% JSYS (.GOMDD)  . . . . . . . . . . . . . .  23
        5.2.25    MTA Access (.GOMTA)  . . . . . . . . . . . . . .  23
        5.2.26    Secure CHFDB% (.GOCFD) . . . . . . . . . . . . .  23
        5.2.27    Secure DELF% (.GODLF)  . . . . . . . . . . . . .  24
Enhanced Access Control Facility Functional Specification       Page 3


        5.2.28    Secure OPENF% (.GOOPN) . . . . . . . . . . . . .  24
        5.2.29    Secure RNAMF% (.GORNF) . . . . . . . . . . . . .  24
        5.2.30    Set Time (.GOSTD)  . . . . . . . . . . . . . . .  25
        5.2.31    SMON% JSYS (.GOSMN)  . . . . . . . . . . . . . .  25
        5.2.32    Structure Mount (.GOSMT) . . . . . . . . . . . .  25
        5.2.33    SYSGT% JSYS (.GOSGT) . . . . . . . . . . . . . .  25
        5.2.34    Terminal Speed (.GOTBR)  . . . . . . . . . . . .  25
        5.2.35    TLINK% JSYS (.GOTLK) . . . . . . . . . . . . . .  26
        5.2.36    TTMSG% JSYS (.GOTTM) . . . . . . . . . . . . . .  26
        5.2.37    USER-TEST (400000) . . . . . . . . . . . . . . .  26
        5.3       Sample ACJPROFILE.CMD  . . . . . . . . . . . . .  26
        5.4       Access Control Log Files . . . . . . . . . . . .  28
        5.4.1     Log File Format  . . . . . . . . . . . . . . . .  28
        5.4.2     Log File Examples  . . . . . . . . . . . . . . .  29
        5.5       Secure Files and ACCESS.CONTROL  . . . . . . . .  30
        5.5.1     Secure File Policy Implementation  . . . . . . .  30
        5.5.2     Format of ACCESS.CONTROL . . . . . . . . . . . .  31
        5.5.3     Examples of ACCESS.CONTROL Files . . . . . . . .  31
        6.0     Services Required  . . . . . . . . . . . . . . . .  33
        7.0     Major Algorithms . . . . . . . . . . . . . . . . .  33
        8.0     Performance Expectations . . . . . . . . . . . . .  34
        9.0     Error Handling . . . . . . . . . . . . . . . . . .  35
        10.0    Diagnostic Features  . . . . . . . . . . . . . . .  35
        11.0    Documentation Impact . . . . . . . . . . . . . . .  35
        12.0    Constraints and Tradeoffs  . . . . . . . . . . . .  35
        13.0    Packaging/Building/Installation  . . . . . . . . .  36
        14.0    Revision History . . . . . . . . . . . . . . . . .  37
Enhanced Access Control Facility Functional Specification       Page 4


     1.0  Summary of Functional Change

     1.1  Changes from 7(130) to 7(131)

          The only change in edit 131 is to change the GOATJ  (Attach  Job)
     policy  to  allow  attach  of  not-logged-in jobs to terminals for the
     FTPSRT program (FTPSRT is the program allowing TCP/IP  network  access
     to files).



     1.2  Changes from 7(105) to 7(130)

          The first release of this software was version 7(105).

          Changes to ACJDEC.MAC in edits 106 to 130 are documented below.

     1.  Addition of a cache for the log  file,  which  is  a  write-behind
         cache used to buffer log file writes.

         The log file is now updated every few seconds (or whenever  it  is
         about  to be read or renamed).  The addition of the log file cache
         causes no externally visible changes  to  the  software  but  does
         improve ACJ performance.  The log file cache sweep interval can be
         set in the profile generation phase and defaults  to  30  seconds.
         The  cache  can  be  disabled  by setting the log file cache sweep
         interval to zero.  The command  SET  LOG-FILE-CACHE-SWEEP-INTERVAL
         is used to change this value.

     2.  Addition of a cache for the ACCESS.CONTROL files.

         The ACCESS.CONTROL cache is organized  into  NCACHE  (default  16)
         non-contiguous  fixed  buffers  in memory, each of SCACHE (default
         16) contiguous pages.  A "Cache Block" is allocated for each cache
         entry  and contains the address of the buffer as and the directory
         for this entry.  When the cache is full the entry with the  oldest
         reference  date  is  reclaimed  for  use.   The  addition  of  the
         ACCESS.CONTROL cache causes no externally visible changes  to  the
         software  but  does  improve  ACJ  performance significantly.  The
         cache hit/access ratio is now output in the log file  header  line
         as a percentage.

     3.  Summary information is now written to the  log  file  when  it  is
         closed.

     4.  The ACCESS.CONTROL files are now properly  read  if  they  contain
         line numbers (as generated by a text editor such as EDIT).

     5.  The ACJLOG tool is now included which can filter and summarize the
         access control log files (see ACJLOG.HLP for more information).

     6.  If the access control log filespec is found to have a  "*"  in  it
         the   current   date   and   time  are  substituted  in  the  form
         "yyyy-mm-dd-hh-mm-ss".
Enhanced Access Control Facility Functional Specification       Page 5


     7.  Two new GETOK functions were added:  GET-DIRECTORY  (GTDIR%  JSYS)
         and SET-TIME (STAD% JSYS).  These are documented in the main text.

     8.  A bug in the CREATE-DIRECTORY policy was fixed  which  caused  all
         directory  deletions  (using  KILL subcommand of BUILD command) to
         fail.  This was due to  a  RCDIR%  JSYS  in  the  CREATE-DIRECTORY
         policy  routine.  The RCDIR% caused the target directory to be put
         in the directory cache;  the kill would then fail with  the  error
         "Directory  file  is  mapped".   The  fix  was  that if the target
         directory was being killed, do a RCDIR% JSYS on another directory,
         causing the target directory to be removed from the cache.




     1.3  Problem Discussion and History

          The current ACJ we  use  here  has  been  hacked  over  from  the
     original ACJ.MEM file shipped with the GETOK/RCVOK/GIVOK interface was
     created.  It is hard to maintain and contains no discernable  coherent
     layout or style.

          The ACJ.MEM file distributed to customers is outdated in that  it
     doesn't  have  a full implementation of all of the currently supported
     GETOK functions and also is in poor style.

          The TOPS-20  Security  Project  is  significantly  enhancing  the
     amount  and  type  of  data  returned by the GETOK interface and major
     changes will be needed in the user written ACJ code to take  advantage
     of these new items.



     1.4  Description and Goals

          Rather than continuing to modify the locally grown  ACJ  program,
     the  ACJ program will be broken down into two logical parts:  the main
     ACJDEC.MAC module and the  subroutine  module  ACJUSR.MAC.   A  module
     ACJSYM.MAC will contain common symbols.

          The  ACJUSR.MAC  files  will  implement  the  policy,   and   the
     ACJDEC.MAC  will  contain  all  GETOK/GIVOK  code  as  well as general
     subroutines (such as used for logging or  getting  information).   The
     policy enforced by the current ACJ will be used as a basis for the new
     ACJ.  For internal use the old or the new ACJ can be run as the system
     ACJ.

          The new ACJ program will be written to adhere to  TOPS-20  Coding
     Standards  and  with  the  goals  of  easy debugging, maintenance, and
     supportability.  It is also a goal of this project to distribute  this
     ACJ to the customer base.

          The user will execute ACJDEC.MAC, ACJUSR.MAC which will  start  a
     "ACJ  Profile" phase in which commands are accepted from the terminal.
     These commands control the policy implemented by the ACJ.
Enhanced Access Control Facility Functional Specification       Page 6


          The ACJ.EXE resulting from the generation phase will not have the
     capability  to change its policy operation.  The ACJ.EXE file will not
     contain symbols or the  command  interface,  unless  overridden  by  a
     compile time switch.



     1.5  Limitations and Restrictions

          Is it not a goal  of  this  project  to  enhance  performance  or
     reliability over the previously distributed ACJ.MEM file.

          Running this ACJ program will  not  protect  the  system  against
     security problems, but it will enhance the security of the system.



     1.6  Supporting Information

          For more information on the new GETOK functions to be implemented
     as  part  of  the  TOPS-20  Security  Enhancements  Project,  see  the
     Functional Specification for Security Enhancements.



     1.7  Security Consciousness

          Security is something that must be maintained on many levels in a
     computer  system  environment.   It  is  important that each site take
     reasonable care  in  protecting  the  security  of  the  system.   The
     computer  hardware  must be physically secure as well as insuring that
     the computer software is secure.

          It must be remembered that running  an  ACJ  does  not  make  the
     system  secure.   A  properly  configured  and  running  ACJ is only a
     portion of what must be done.

          It is important to take security measures before  the  system  is
     violated.  It is suggested that the following also be done in order to
     provide a secure atmosphere:

     1.  Usernames:  No username should be used by more that one person  at
         a  time.   It  is  important that each person accessing the system
         should do so with a username uniquely  assigned  to  that  person.
         Sharing  usernames  hampers  or in some cases prevents auditing of
         security problems.

     2.  Passwords:  The TOPS-20 monitor provides a number of features that
         help  in  password  management.   It is suggested that the minimum
         password length be  set  to  eight  characters.   The  longer  the
         password  is,  the  harder  it  is to guess.  It is suggested that
         password expiration should be set to 30 days.  Passwords that  are
         changed often are more secure than having the same password for an
         extended period  of  time.   The  password  dictionary  should  be
         enabled.   This new feature will prevent the setting of a password
         that is in a common dictionary file, which will make the  password
Enhanced Access Control Facility Functional Specification       Page 7


         harder to guess.

     3.  Capabilities:  Since a user with WHEEL or OPERATOR capability  has
         the  power  to  change many aspects of system operation, the WHEEL
         and OPERATOR capabilities should be set on the minimum  number  of
         usernames on the system.  A need to access files should be handled
         by the existing directory and user groups  structure  and  not  by
         handing  out  OPERATOR  capability.   Please  note  that  it  is a
         particularly BAD idea to have one username with WHEEL or  OPERATOR
         that a number of persons use.

     4.  Backups:  A "system tape"  (containing  the  monitor,  exec,  user
         information,  and  system  files from the bootable file structure)
         should be created once a week.  Not only is  this  useful  in  the
         case  of  hardware failures, but can be used to get a known secure
         copy of the monitor and all other software running on  the  system
         with enabled capabilities.

     5.  FILES-ONLY directories:  Directories on the system's PS: structure
         that are not normally user for usernames should be set FILES-ONLY.
         This prevents "accidental" usernames from being created which  are
         obvious security problems.

     6.  OPERATOR username:  It is suggested that the OPERATOR username  be
         prevented  from  logging in interactively by removing its password
         (or expiring its password).  OPERATOR should be used to  run  jobs
         needed  for system operator (e.g.  jobs under SYSJOB and/or PTYCON
         that are logged in when the system is reloaded).  A password  does
         not  have  to  be  set  on  OPERATOR in order for jobs to login to
         OPERATOR under SYSJOB or PTYCON.  The system operator  should  use
         his/her own username to run the system backups and to run OPR.  If
         it is desired that OPERATOR run DUMPER to save  the  system,  this
         can be done under PTYCON.

     7.  ACJ  Policy:   The  ACJ  program  provides  a  critical   security
         function.   The  program should be tailored at the site to provide
         the access control and logging that the site requires.   This  ACJ
         implements  an access policy that lets users with WHEEL capability
         do more than users with OPERATOR capability (see the Login, Attach
         Job,   and   Create   Directory   policy   descriptions  for  more
         information).

     8.  Secure Files:  This ACJ along with the TOPS-20  monitor  with  the
         security  project edits allows user selectable control and logging
         of file access.  It is suggested that files that are sensitive  to
         the  operation and health of the system be set SECURE and activity
         should be monitored by looking at the ACJ log files.  These  files
         would    certainly   include   MONITR.EXE   and   EXEC.EXE.    The
         ACCESS.CONTROL files should also be set secure.  Secure files  and
         ACCESS.CONTROL are discussed elsewhere in this document.

     9.  ACJ Logs:  The log files produced by  the  site's  ACJ  should  be
         reviewed  daily for possible unusual activity.  Careful monitoring
         will result in greater system security since  repeat  penetrations
         are the cause of the most severe security problems.
Enhanced Access Control Facility Functional Specification       Page 8


    10.  Local Changes:  It is important not to underestimate the  positive
         effect  that  a  few minor site specific changes have on security.
         Anything that makes the site's system just a little different will
         slow down an attempted breakin.  For example, it is suggested that
         the site use the commands available in this ACJ to change the  ACJ
         log filename from the default.


          Maintaining system security on a TOPS-20 7.0  system  isn't  very
     difficult.   It is just a matter of using the provided tools and using
     common sense.



     2.0  Terminology

          It is assumed that the reader has  a  basic  knowledge  of  terms
     relating to TOPS-20 monitor calls, but this is not a requirement.

     1.  ACJ - Access  Control  Job  (Access  Control  Facility).   TOPS-20
         allows  a  site  supplied  program  to  implement policy decisions
         relating  to  system  resources.   The  ACJ  is  a  program   that
         implements policy and control over system functions on as per site
         basis.  Each site should have an ACJ to implement policy based  on
         the needs of that site.

     2.  CTERM - A protocol  used  to  simulate  remote  terminal  sessions
         communicated over DECnet.

     3.  GETOK - Action performed (usually by the monitor through the GTOKM
         macro) to ask the ACJ for permission to perform a certain function
         or obtain ownership of a certain object.

     4.  NRT -  A  protocol  used  to  simulate  remote  terminal  sessions
         communicated  over  DECnet.   An  older  protocol  that  has  been
         superseded by CTERM.

     5.  TCP/IP - Transmission Control Protocol / Internet  Protocol.   The
         network   protocol   used   by  many  different  computer  systems
         manufacturers.

     6.  TELNET - A protocol used to simulate remote terminal sessions over
         TCP/IP.




     3.0  Architectural Position

          The ACJ program is consulted by the monitor on certain events  in
     order  that  local  policy  can be implemented.  This spec describes a
     program that is one implementation of the ACJ.
Enhanced Access Control Facility Functional Specification       Page 9



                                     +---------+
              ACJPROFILE             | ACJDEC  |
                 command ----------->| profile |
                   file  <-----------| program |
                                     +---------+
                                          |
                                          V
             +---------+             +---------+
             | TOPS-20 |---RCVOK%--->|   ACJ   |
             | monitor |             |  policy |
             |  code   |<---GIVOK%---| program |----> log file
             +---------+             +---------+
                     



     3.1  Access Control Profile Generation

          When the  Access  Control  Facility  profile  generation  program
     (ACJDEC.EXE)  is  run, it will parse commands from the terminal to set
     the profile for each possible GETOK function and  for  each  "special"
     user.  After this process is complete, a command will be used to write
     the current settings into a command file that  can  be  processed  for
     future profile setting sessions.

          When the system manager is  satisfied  with  the  Access  Control
     Profile  and  has  written  the  command  file,  the policy program is
     written.  This EXE file implements the Access Control policy.



     3.2  Access Control Facility Operation

          The Access Control Facility policy program (ACJ.EXE) is run as  a
     user  program.   It interfaces to the TOPS-20 monitor using the RCVOK%
     and GIVOK% monitor calls.

          When the monitor wishes to have the ACJ bless some operation,  it
     puts  a  request into the GETOK Queue.  The GETOK Queue is read by the
     RCVOK% JSYS.  If the entry is not removed from the GETOK  Queue  in  a
     reasonable  amount  of time, a RCVTMR BUGCHK is issued and the monitor
     ignores the running Access Control Facility.

          After the ACJ reads the request  with  RCVOK%,  it  may  log  the
     request  and  will  decide  to  allow or deny it.  This information is
     communicated to the monitor by using the GIVOK% JSYS.

          For each request read by RCVOK%, a GIVOK% JSYS must be  executed.
     If  the  GIVOK%  is  not  executed in a reasonable amount of time, the
     monitor issues a GIVTMR BUGCHK  and  allows  or  denies  the  function
     (based on the function's default action).
Enhanced Access Control Facility Functional Specification      Page 10


     3.3  Program Organization

          The three source files that create the profile generation program
     are  called  ACJSYM.MAC,  ACJUSR.MAC, and ACJDEC.MAC.  ACJSYM contains
     all  macro  and  symbol  definitions.   ACJDEC  contains  the  profile
     generation  code,  the  main RCVOK%/GIVOK% processing loop, and common
     subroutines.  The ACJUSR module contains  tables  for  GETOK  function
     definitions  (used in profile and policy phases), and logging routines
     and policy routines for each function.



     4.0  Related Documents and Standards

          Documents that relate to this  functional  specification  are  as
     follows.

      o  TOPS-20 Functional  Specification  of  Security  Enhancements,  M.
         Raspuzzi, November 1988

      o  TOPS-20 Monitor Calls Reference Manual, Jun 88, (AA-FV52B-TM)

      o  TOPS-20 Coding Standards, D. Murphy, March 1983

      o  Final Report on  Proposed  TOPS-20  Security  Enhancements,  David
         Velten, 5 Oct 1982, DEC TR-188




     5.0  Services Provided

     5.1  Access Control Profile

          When the profile generation program  (ACJDEC)  is  run,  it  will
     prompt  for  commands.   A  brief  description of each of the commands
     follows.



     5.1.1  Disable Command

          The DISABLE command is used to disable the  policy  program  from
     receiving GETOK requests for a particular GETOK function.  The DISABLE
     command is followed by a keyword describing the GETOK function.  These
     keywords are also used for the ENABLE command.  The keywords and their
     corresponding GETOK functions are:

      o  ACCESS (.GOACC)

      o  ARPANET-ACCESS (.GOANA)

      o  ASSIGN-DEVICE (.GOASD)
Enhanced Access Control Facility Functional Specification      Page 11


      o  ASSIGN-DUE-TO-OPENF (.GOOAD)

      o  ATTACH-JOB (.GOATJ)

      o  CAPABILITIES (.GOCAP)

      o  CLASS-ASSIGNMENT (.GOCLS)

      o  CLASS-SET-AT-LOGIN (.GOCL0)

      o  CREATE-DIRECTORY (.GOCRD)

      o  CREATE-FORK (.GOCFK)

      o  CREATE-JOB (.GOCJB)

      o  CREATE-LOGICAL-NAME (.GOCRL)

      o  CTERM (.GOCTM)

      o  DECNET-ACCESS (.GODNA)

      o  DETACH (.GODTC)

      o  ENQ-QUOTA (.GOENQ)

      o  GET-DIRECTORY (.GOGTD)

      o  GETAB (.GOGTB)

      o  HSYS (.GOHSY)

      o  INFO (.GOINF)

      o  LATOP (.GOLAT)

      o  LOGIN (.GOLOG)

      o  LOGOUT (.GOLGO)

      o  MDDT (.GOMDD)

      o  MTA-ACCESS (.GOMTA)

      o  SECURE-CHFDB (.GOCFD)

      o  SECURE-DELF (.GODLF)

      o  SECURE-OPENF (.GOOPN)

      o  SECURE-RNAMF (.GORNF)

      o  SET-TIME (.GOSTD)
Enhanced Access Control Facility Functional Specification      Page 12


      o  SMON (.GOSMN)

      o  STRUCTURE-MOUNT (.GOSMT)

      o  SYSGT (.GOSGT)

      o  TERMINAL-SPEED (.GOTBR)

      o  TLINK (.GOTLK)

      o  TTMSG (.GOTTM)

      o  USER-TEST (function code 400000)


          The keyword ALL can be specified to indicate all functions.



     5.1.2  Enable Command

          The ENABLE command is used to enable the policy program's receipt
     of  GETOK  functions.   The  ENABLE  command  is followed by a keyword
     describing which GETOK function to enable (see  previous  section  for
     listing  of  these  functions).   After  the  function,  the following
     keywords can be specified:

      o  [NO] CONSOLE

         The CONSOLE keyword enables display of the logging string  to  the
         console terminal.  NO CONSOLE is the default.

      o  [NO] DENY-BATCH

         The DENY-BATCH keyword causes a request for this function from any
         batch job to always be denied.  The default is NO DENY-BATCH.

      o  [NO] DENY-CTY

         The DENY-CTY keyword causes a request by a  job  logged  into  the
         system's  console  terminal  (the  CTY)  to always be denied.  The
         default is NO DENY-CTY.

      o  [NO] DENY-DECNET

         The DENY-DECNET keyword  causes  a  request  by  a  job  which  is
         attached  to  the system through DECnet (NRT or CTERM protocol) to
         always be denied.  The default is NO DENY-DECNET.

      o  [NO] DENY-DETACHED

         The DENY-DETACHED keyword causes a request by a  detached  job  to
         always be denied.  The default is NO DENY-DETACHED.
Enhanced Access Control Facility Functional Specification      Page 13


      o  [NO] DENY-LAT

         The DENY-LAT keyword causes a request by a  job  attached  to  the
         system through a LAT terminal to always be denied.  The default is
         NO DENY-LAT.

      o  [NO] DENY-LOCAL

         The DENY-LOCAL keyword causes a request by a job logged  into  any
         terminal  local to the system to always be denied.  The default is
         NO DENY-LOCAL.

      o  [NO] DENY-PTY

         The DENY-PTY keyword causes a request by a job attached to  a  PTY
         that  is  not  a batch job to always be denied.  The default is NO
         DENY-PTY.

      o  [NO] DENY-TCP

         The DENY-TCP keyword causes a request by a  job  attached  to  the
         system  through TCP/IP (TELNET protocol) to always be denied.  The
         default is NO DENY-TCP.

      o  [NO] LOG

         The LOG keyword causes  a  line  describing  the  function  to  be
         written  to  the ACJ log file.  The logging function is completely
         independent of policy enforcement.  The default is LOG.

      o  [NO] POLICY

         The POLICY keyword causes enforcement of policy on this  function.
         If  the  function  is  set  NO POLICY, access is denied or allowed
         based on the monitor's default action  for  this  GETOK  function.
         POLICY is enabled by default.




     5.1.3  Help Command

          The HELP command displays a help message in the following format:

     ACJ 7(22) commands:

       DISABLE (function) ALL|name
       ENABLE (function) ALL|name [profile]
       HELP (message)
       SAVE (program in) ACJ.EXE
       SET (mode) keywords
       SHOW ALL|FUNCTION [f]|SETTING [s]|USER [u]
       TAKE (commands from) acjprofile.cmd.0
       USER name [profile]
       WRITE (commands to) acjprofile.cmd.-1
Enhanced Access Control Facility Functional Specification      Page 14


     5.1.4  Save Command

          The SAVE command is used to save a EXE file which is  the  policy
     program implementation.  The default filename is ACJ.EXE.



     5.1.5  Set Command

          The SET command is used to change policy program  settings.   The
     SET command is followed by one of the following:

      o  ACCESS-LOG-FILE filespec

         Set the log filespec.  The default filespec is SYSTEM:LOGFILE.LOG.

      o  LOG-FILE-CACHE-SWEEP-INTERVAL n

         Sets the log file cache sweep interval.  The log file  is  updated
         every few seconds (or whenever it is about to be read or renamed).
         The log file cache sweep interval defaults  to  30  seconds.   The
         cache can be disabled by setting the log file cache sweep interval
         to zero;  this will force the log file to be updated each  time  a
         line is written to it.

      o  PRIME-TIME-BEGIN time

         Sets the time at which prime time begins on  each  weekday.   This
         time  is  used  when the user profile is set ENABLE-PRIME-TIME for
         the CAPABILITIES (.GOCAP) function.  If the desired action  is  to
         let anyone enable at any time, the CAPABILITIES function should be
         enabled with NO POLICY or disabled.  The default prime time  begin
         is 07:00 (7 AM).

      o  PRIME-TIME-END time

         Sets the time at which prime time ends on each weekday.  This time
         is  used  when  the  user profile is set ENABLE-PRIME-TIME for the
         CAPABILITIES (.GOCAP) function.  If the desired action is  to  let
         anyone  enable  at  any  time, the CAPABILITIES function should be
         enabled with NO POLICY or disabled.  The default  for  prime  time
         end is 18:00 (6 PM).

      o  SPY-CHECK-INTERVAL seconds

         Sets the time between TLINK%s to jobs that  are  being  spyed  on.
         Longer times lower overhead but increase the risk that spying data
         will be lost.  Shorter times increase overhead but lower the  risk
         that spying data will be lost.  The default is 10 seconds.

      o  SPY-LOG-DIRECTORY string

         Sets the initial part of the filespec used to write spy logs into.
         The string specified will have "-nodename.username" appended to it
         in  order  to  create  the   log   filespec.    The   default   is
         SYSTEM:ACJ-SPY,   so   spy   log   files  would  be  of  the  form
Enhanced Access Control Facility Functional Specification      Page 15


         "SYSTEM:ACJ-SPY-nodename.username".  These files are  always  made
         SECURE by the ACJ.




     5.1.6  Show Command

          The SHOW command is used to display  the  various  items  changed
     with  the ENABLE, DISABLE, SET, and USER commands.  The SET command is
     followed by any of the following.

      o  ALL

         Shows all information possible.

      o  FUNCTION ALL|keyword

         Shows profile of all functions or a particular function.

      o  SETTINGS ALL|keyword

         Shows all items or a particular item changed by the SET command.

      o  USER ALL|userspec

         Shows all user profiles or a particular user profile.




     5.1.7  Take Command

          The TAKE command is used to process a file with commands  in  it.
     It  takes  one  argument,  which  is  the  filename, which defaults to
     ACJPROFILE.CMD.



     5.1.8  User Command

          The USER command is used to set a user profile entry.  The  first
     argument  to the USER command is the wild user specification that this
     profile is going to apply to (e.g.  "OPERATOR",  "STAFF.*").   A  user
     specification  of  "*"  is allowed, and will be used for all users not
     otherwise found in the table.

          The wild user specification is followed by keywords that set  the
     user profile.  The keywords are:

      o  CLASS-AT-LOGIN n

         Sets scheduler class "n" at login (.GOCL0 function).  All jobs are
         created in scheduler class 0.  The .GOCL0 function is only invoked
         by the monitor if if the class scheduler  is  enabled  with  class
         assignment by policy program.  The default is CLASS-AT-LOGIN 0.
Enhanced Access Control Facility Functional Specification      Page 16


      o  [NO] ENABLE-NON-PRIME-TIME

         Can enable capabilities at times other than 7 AM to 6 PM  weekdays
         (.GOCAP  function).  If the desired action is to let anyone enable
         at any time, the CAPABILITIES function should be enabled  with  NO
         POLICY or disabled.  The default is NO ENABLE-NON-PRIME-TIME.

      o  [NO] LOGIN-BATCH

         The LOGIN-BATCH keyword lets batch jobs login.  The default is  NO
         LOGIN-BATCH.   Note  that the LOGIN-PTY keyword is used to control
         non-batch PTY logins.

      o  [NO] LOGIN-CTY

         The LOGIN-CTY keyword lets a job login to the system  through  the
         system's console terminal (the CTY).  The default is LOGIN-CTY.

      o  [NO] LOGIN-DECNET

         The LOGIN-DECNET keyword lets a job login to  the  system  through
         DECnet  using  NRT  or CTERM protocol.  This keyword should not be
         confused with remote DECnet access  using  the  RMSFAL  (which  is
         controlled   by  the  LOGIN-DETACHED  keyword).   The  default  is
         LOGIN-DECNET.

      o  [NO] LOGIN-DETACHED

         The LOGIN-DETACHED keyword lets a  job  login  detached.   Digital
         supplied  software  that  does  detached  logins is limited to DIU
         (Data Interchange Utility) and RMSFAL (RMS File Access  Listener).
         If  DECnet  access  is  desired  using DIU or RMSFAL then the user
         profile must be set LOGIN-DETACHED.  The LOGIN-DECNET  keyword  is
         used  to to control interactive LOGIN over DECnet.  The default is
         LOGIN-DETACHED.

      o  [NO] LOGIN-LAT

         The LOGIN-LAT keyword lets a job login to the system through a LAT
         terminal.  The default is LOGIN-LAT.

      o  [NO] LOGIN-LOCAL

         The LOGIN-LOCAL  keyword  lets  a  job  login  to  terminal  lines
         connected  to the DECSYSTEM-20 (RSX20F console front end) that are
         not configured as "REMOTE".  LOCAL lines  are  normally  connected
         directly to terminals rather than to communications equipment such
         as modems or port selecters.  The default is LOGIN-LOCAL.

      o  [NO] LOGIN-PTY

         The LOGIN-PTY keyword lets a job login to a  PTY  that  is  not  a
         batch  job  to succeed (the LOGIN-BATCH keyword is used to control
         batch logins).  The default is LOGIN-PTY.
Enhanced Access Control Facility Functional Specification      Page 17


      o  [NO] LOGIN-REMOTE

         The LOGIN-REMOTE keyword  lets  a  job  login  to  terminal  lines
         connected  to the DECSYSTEM-20 (RSX20F console front end) that are
         configured as "REMOTE".  REMOTE lines are  normally  connected  to
         modems  or port selecting equipment and not directly to terminals.
         The default is LOGIN-REMOTE.

      o  [NO] LOGIN-TCP

         The LOGIN-TCP keyword lets a job login to  the  system  through  a
         TCP/IP terminal (TELNET protocol).  The default is LOGIN-TCP.

      o  [NO] SPY-ON

         Will be spyed on when logging in or attaching (.GOLOG  and  .GOATJ
         functions).  The default is NO SPY-ON.


          The  keywords  used  to  control  LOGINs  are  normally  used  in
     combination.   For example if a user should only be able to LOGIN from
     batch and for DECnet access using RMSFAL, the user should  be  set  NO
     LOGIN-CTY  NO LOGIN-DECNET NO LOGIN-LAT NO LOGIN-LOCAL NO LOGIN-PTY NO
     LOGIN-REMOTE NO LOGIN-TCP (only LOGIN-BATCH and  LOGIN-DETACHED  would
     be allowed).



     5.1.9  Write Command

          The  WRITE  command  is  used  to  extract  all  current  profile
     information  and  write it to a command file.  The WRITE command takes
     one argument, which is the filename, which defaults to ACJPROFILE.CMD.



     5.2  Access Control Policy

          For each GETOK function a policy and logging  is  implemented  by
     the  ACJUSR  module.   All monitor supplied additional information for
     each GETOK function is logged (if the function is set LOG or CONSOLE).

          The implemented policy  is  explained  for  each  GETOK  function
     below.   If the implemented policy is not desired, the function can be
     enabled with NO POLICY, or the customer may choose to edit  ACJUSR.MAC
     and implement a local policy.



     5.2.1  Access (.GOACC)

          The ACCES% monitor call is used to implement the  EXEC's  ACCESS,
     CONNECT,  and  END-ACCESS commands.  The monitor calls the ACJ only if
     the  user  is  not  WHEEL  or  OPERATOR,  the  user  does   not   have
     directory/user   group   access,  and  the  user  gave  bad  password.
     Therefore this request is normally almost always denied.
Enhanced Access Control Facility Functional Specification      Page 18


          The policy implemented is to allow a directory's owner to  always
     connect  to  his/her  "owned"  subdirectories.  The subdirectories are
     defined as all "<username*>" directories on any file structure that is
     DOMESTIC.   To  log  all failed ACCESS or CONNECT commands but prevent
     users from connecting to their owned subdirectories without a password
     or directory/user group access, enable this function with NO POLICY.



     5.2.2  Arpanet Access (.GOANA)

          The monitor calls the ACJ with this function code for each TCP/IP
     OPENF%  (each  time  a  user  attempts to initiate an outgoing Arpanet
     connection).

          The implemented  policy  allows  access  for  users  with  SC%ANA
     capability  only.   To  log  all  Arpanet  access  and allow all users
     Arpanet access, enable this function with NO POLICY.



     5.2.3  Assign Device (.GOASD)

          The ASND% JSYS is used to implement the  EXEC's  ASSIGN  command.
     The  monitor  invokes  the  ACJ with this function code for each ASND%
     JSYS.

          The implemented policy is to only allow users with enabled  WHEEL
     or  OPERATOR  to  assign  MTA devices.  This is to prevent non-enabled
     users from assigning tape drives that  are  set  UNAVAILABLE  (by  OPR
     command).  All other devices are allowed.



     5.2.4  Assign Due To OPENF% (.GOOAD)

          The OPENF% monitor call is used to open a device  for  use.   The
     monitor  calls  ACJ  for each assignment of a device due to an OPENF%.
     This function is very similar to the Assign Device (.GOASD)  function.
     The difference is that the assign of a device happens because the user
     has opened the device with OPENF% rather  than  assigning  the  device
     with  ASND%.   For  example  if  a  user  tries to open TTY1:  without
     assigning it to his job first (ASSIGN TTY1:), the monitor assigns  the
     device to the user before letting the OPENF% proceed.  The only device
     that is not assigned in this manner are file structures (disks).

          The implemented policy is the same as the Assign Device function;
     to  only  allow  users  with  enabled  WHEEL or OPERATOR to assign MTA
     devices.  As with the assign  device  function,  this  is  to  prevent
     non-enabled  users from assigning tape drives that are set UNAVAILABLE
     (by using the OPR command).  All other devices are allowed.

          To log all assignments of devices and enable MTA  devices  to  be
     assigned  enable  this function and the Assign Device function with NO
     POLICY.
Enhanced Access Control Facility Functional Specification      Page 19


     5.2.5  Attach Job (.GOATJ)

          The ATACH% JSYS is used to implement the EXEC's  ATTACH  command.
     The monitor calls the ACJ on each ATACH% monitor call.

          The attach is denied if:

      *  The job is a batch job (batch cannot attach to anything).

      *  The target job's user profile says that target user  cannot  LOGIN
         to the source's line type.

      *  WHEEL-only LOGINs are set for the source line type and the  target
         job is not WHEEL user.

      *  The target job is batch job and source  job  is  not  and  enabled
         WHEEL.

      *  The source job has OPERATOR capabilities enabled  and  the  target
         job is a user with WHEEL (the monitor would usually let the attach
         happen without a password).  This prevents a  user  with  OPERATOR
         capability  from  attaching  to  a job with WHEEL capability in an
         effort to gain WHEEL capability.

      *  The source job is controlled by a user  with  OPERATOR  capability
         and the target job is a user with WHEEL capability.  This prevents
         a user with OPERATOR capability from attaching to a job with WHEEL
         capability in an effort to gain WHEEL capability.




     5.2.6  Capabilities (.GOCAP)

          The EPCAP% monitor call is invoked with  the  EXEC's  ENABLE  and
     DISABLE commands.  The monitor calls the ACJ for each EPCAP% JSYS.

          The policy routine disallows setting of WHEEL or OPERATOR  during
     non-prime    time    unless    the   user   profile   has   been   set
     ENABLE-NON-PRIME-TIME.  If the desired action is to let anyone  enable
     at  any  time,  the  CAPABILITIES  function  should be enabled with NO
     POLICY or disabled.



     5.2.7  Class Assignment (.GOCLS)

          The monitor calls the  ACJ  for  all  attempts  to  set  a  job's
     scheduler  class  using  the  SKED%  JSYS.  The OPR command "SET JOB x
     SCHEDULER-CLASS y" is an example of this.  However, if a user  is  not
     WHEEL  or  OPERATOR  and is trying to set another job's class, the ACJ
     will not be consulted and the user will get a CAPX1 error.

          The policy routine only allows WHEEL or OPERATOR jobs to change a
     job's  scheduler  class (the same check that is currently performed by
     the monitor).
Enhanced Access Control Facility Functional Specification      Page 20


     5.2.8  Class Set At Login (.GOCL0)

          The monitor calls the ACJ with this function code each time a job
     logs in only if the class scheduler is on and class assignments are by
     the policy program.

          The policy implemented is to use a SKED% JSYS to set the job in a
     particular  class as specified by the user profile CLASS-AT-LOGIN.  As
     class zero is the  default  class,  no  SKED%  JSYS  is  done  if  the
     CLASS-AT-LOGIN in the user profile is set to zero (or there is no user
     profile associated with the user logging in).  If the  job  cannot  be
     set in the proper class, the log entry is marked as "unusual".



     5.2.9  Create Directory (.GOCRD)

          The CRDIR%  JSYS  is  used  by  the  EXEC's  ^ECREATE  and  BUILD
     commands.  The monitor calls the ACJ on each and every CRDIR% JSYS.

          In monitor's  previous  to  the  implementation  of  the  TOPS-20
     Security  Enhancement  project,  the  monitor  does not furnish us the
     user's CRDIR% arguments;  in this case we attempt to get them from the
     monitor  by using a combination of the SNOOP% and XPEEK% monitor calls
     and the PMOVE (physical move) instruction.  The PMOVE  instruction  is
     only  implemented  in  KL10  microcode  version  442  and later.  This
     microcode is required for TOPS-20  version  7.0  and  will  work  with
     TOPS-20 version 6.1.

          It is very important to not  allow  <ROOT-DIRECTORY>  to  have  a
     password,  user  groups,  directory groups, or be non-files-only.  The
     reason is that  if  someone  is  allowed  to  ACCESS  or  CONNECT  the
     <ROOT-DIRECTORY>  or  LOGIN  to  ROOT-DIRECTORY then this person would
     have  owner  access  to  the  ROOT-DIRECTORY  and  any  directory  (or
     username) on that structure could be changed without enabling WHEEL or
     OPERATOR.   The  implemented  policy  denies  setting  of  a  non-null
     password or any user or directory groups on any <ROOT-DIRECTORY>.

          In addition, the policy implemented controls access  to  DOMESTIC
     file structures.  The policy routine only lets enabled WHEELs change a
     directory's SECURE, FILES-ONLY, WHEEL, OPERATOR, or SEMI-OPERATOR bits
     if  the  structure is DOMESTIC.  Also non-WHEEL users have to make all
     NEW directories FILES-ONLY, NO SECURE, and with no capabilities.   The
     Boot  Structure  (BS:)  and  the  Public  Structure  (PS:)  are always
     DOMESTIC and cannot be made FOREIGN.  Therefore, users  with  OPERATOR
     capability  are  prevented  from making new usernames or significantly
     changing existing usernames on DOMESTIC structures.



     5.2.10  Create Fork (.GOCFK)

          Each time a user runs a program, a  process  (fork)  is  created.
     The  CFORK%  JSYS  is used to create forks.  The monitor calls the ACJ
     for each CFORK% that creates  more  than  FKCNT  forks.   FKCNT  is  a
     monitor cell that may be patched by customers, and is defaulted to 5.
Enhanced Access Control Facility Functional Specification      Page 21


          The policy routine always allows the CFORK%.



     5.2.11  Create Job (.GOCJB)

          The monitor calls the ACJ for each CRJOB% JSYS.

          The policy routine only allows enabled  WHEELs  or  OPERATORs  to
     perform  the  CRJOB%.   To log all CRJOB created jobs but let any user
     use CRJOB, enable this function with NO POLICY.



     5.2.12  Create Logical Name (.GOCRL)

          The monitor calls the ACJ for each CRLNM% JSYS functions  .CLNS1,
     .CLNSA, or .CLNSY and user is not WHEEL or OPERATOR.

          The policy routine only allows enabled  WHEELs  or  OPERATORs  to
     perform  the CRLNM% (the same check that is currently performed by the
     monitor).



     5.2.13  CTERM Connection (.GOCTM)

          The monitor calls the ACJ from job 0 on  each  CTERM  connection.
     The nodename and/or user name could be checked to allow access to this
     system.  NOTE:  a hostile user program can send over any  source  data
     that it wants to in the CTERM connect message.

          The policy implemented is to always allow the  CTERM  connection,
     since  it is only done by job 0 and the data sent in the CTERM connect
     message is not "secure".



     5.2.14  DECnet Access (.GODNA)

          The monitor calls the ACJ for each DECnet (DCN:) OPENF%.

          This routine allows access for users with SC%DNA capability only.
     To  log  all  DECnet  access and allow all users DECnet access, enable
     this function with NO POLICY.



     5.2.15  Detach (.GODTC)

          The monitor calls us for each DTACH% JSYS.

          The policy routine always allows the DTACH%.
Enhanced Access Control Facility Functional Specification      Page 22


     5.2.16  ENQ Quota Set (.GOENQ)

          The monitor calls the  ACJ  only  if  setting  ENQ  quota  (ENQC%
     function .ENQCC) and the user is not WHEEL or OPERATOR.

          The policy routine only allows WHEEL or OPERATOR to  perform  the
     function (the same check that is performed by the monitor).



     5.2.17  Get Directory (.GOGTD)

          The GTDIR% JSYS is used to get information about a directory.

          The policy implemented is to always allow the GTDIR% to  succeed.
     This function is primarily to assure an audit trail whenever some user
     gets information about a directory (INFORMATION DIRECTORY command).



     5.2.18  GETAB% JSYS (.GOGTB)

          The GETAB% monitor call is used to extract information  from  the
     monitor.   The monitor calls the ACJ for each GETAB% when the previous
     context is not monitor (i.e.  when the GETAB%  is  not  executed  from
     within the monitor).

          Note that enabling this function, particularly with logging, will
     cause  a  high amount of overhead, and may degrade system response, so
     enabling this function must be done with caution.

          The policy routine always allows the GETAB%.



     5.2.19  HSYS% JSYS (.GOHSY)

          The monitor calls the ACJ for each HSYS% JSYS.

          The policy implemented is to only allow users with enabled WHEEL,
     OPERATOR, or MAINTENANCE to shutdown the system.



     5.2.20  INFO% JSYS (.GOINF)

          The INFO% monitor call is used to extract  information  from  the
     monitor  about  systems  in the CFS cluster as well as perform cluster
     send alls (^ESEND/NODE:).  The monitor calls us for  each  INFO%  JSYS
     except  when  it  thinks  that  the  INFO% JSYS is being executed by a
     GALAXY component.

          Note that enabling this function will  cause  a  high  amount  of
     overhead,  and  may degrade system response, so enabling this function
     must be done with caution.
Enhanced Access Control Facility Functional Specification      Page 23


          The implemented policy is to always allow the INFO%.



     5.2.21  LATOP% JSYS (.GOLAT)

          The monitor calls the ACJ on all .LARHC  (request  host  connect)
     functions only.

          The implemented policy is to always  allow  the  LATOP%  only  if
     WHEEL  or OPERATOR is enabled.  To log all LATOP% .LARHC functions and
     allow all users  access  to  LATOP%'s  .LARHC  function,  enable  this
     function with NO POLICY.



     5.2.22  Login (.GOLOG)

          The monitor calls the ACJ for each LOGIN% JSYS.

          The LOGIN is denied if

      *  The user is trying to LOGIN to  ROOT-DIRECTORY  (directory  number
         1).

      *  The user is over quota on the PS:<user> directory.

      *  The user profile specifies that the user cannot LOGIN to this line
         type.

      *  WHEEL-only LOGINs are set and user is not WHEEL.

      *  The LOGIN is on a non-batch PTY, the controlling job has  OPERATOR
         capability,  and  is  trying  to  LOGIN  to  a username with WHEEL
         capability.  This prevents  a  user  with  OPERATOR  from  gaining
         access to a job with WHEEL.


          In addition to the above policy, if the user  is  set  SPY-ON  he
     will  be spyed upon and the LOGIN entry in the log file will be marked
     as "unusual".  Users with SPY-ON enabled are suspected intruders  that
     are attempting to use the system without authorized access.  If use of
     a particular username is suspect, the SPY-ON log files can be used  to
     trace the actions of these these intruders.



     5.2.23  Logout (.GOLGO)

          The monitor calls the ACJ each time a job  wants  to  log  itself
     out.

          The request is denied if the user is over quota on the  PS:<USER>
     directory.
Enhanced Access Control Facility Functional Specification      Page 24


     5.2.24  MDDT% JSYS (.GOMDD)

          The monitor calls the ACJ only if user  is  attempting  to  enter
     MDDT and has WHEEL or OPERATOR capability.

          The implemented policy is to disallow entering MDDT by  any  user
     who  is  not a WHEEL.  To log all MDDT entries functions and allow all
     OPERATOR and WHEEL users to enter MDDT, enable this function  with  NO
     POLICY.



     5.2.25  MTA Access (.GOMTA)

          The monitor calls the ACJ for labelled MTA access where  (1)  the
     label  type  is  TOPS-20  and  access  is  by non-owner and there is a
     protection failure;  (2) if ANSI labels and  volume  accessibility  is
     not  "full";  (3) if EBCDIC labels and accessibility byte is from 1 to
     3 inclusive.

          The implemented policy is to always allow the  access.   An  MTU%
     JSYS  could be used to check the labels on the tape for user access to
     labelled tape.



     5.2.26  Secure CHFDB% (.GOCFD)

          The monitor calls the ACJ for each CHFDB% that clears or sets the
     FB%SEC (secure) bit for a file.

          The implemented policy is to allow the request based on  whatever
     is contained in the ACCESS.CONTROL file.

          If there is no ACCESS.CONTROL file in the same directory  as  the
     secure file, then setting or clearing of the secure bit is allowed and
     the request is logged as unusual.

          There are currently three special cases of changing  FB%SEC  that
     are  always  allowed  without logging in order to preserve the current
     and separate actions of files that aren't secure.  These special cases
     allow a full or incremental restore using DUMPER to work as well as it
     always has.

     1.  A CHFDB to clear FB%SEC on a totally new file  type  always  works
         with  no  logging.   This allows nosecure files to be created in a
         directory  without  some  kind  of  ACCESS.CONTROL  keywords  (for
         example  DUMPER  restoring nosecure files) causing lots of unusual
         logging on files that are not intended to be secure.

     2.  CHFDB not really changing SECURE on  new  file  generation  always
         works with no logging.  This allows new generations of files to be
         copied even if stupid programs (such as FCOPY and DUMPER) set  the
         .FBCTL  word with FB%SEC the same as it is now.  A case of this is
         when DUMPER restores new generations of nosecure files.
Enhanced Access Control Facility Functional Specification      Page 25


     3.  If access is allowed because there is no ACCESS.CONTROL  file  and
         the  user  is  trying  to  clear  FB%SEC,  let this happen without
         logging.   This  happens  when  an  existing  nosecure   file   is
         overwritten  with  new  contents  and the program is attempting to
         clear FB%SEC.   A  case  of  this  is  when  DUMPER  is  restoring
         (overwriting) a nosecure MAIL.TXT.1.




     5.2.27  Secure DELF% (.GODLF)

          The monitor calls the ACJ  for  each  DELF%  or  DELNF%  that  is
     deleting a file set SECURE.

          The implemented policy is to allow the request based on  whatever
     is contained in the ACCESS.CONTROL file.

          If delete access is attempted to a file that is  set  secure  and
     there  is  no  ACCESS.CONTROL file in the same directory as the secure
     file, then access is allowed and the request is logged as unusual.



     5.2.28  Secure OPENF% (.GOOPN)

          The monitor calls the ACJ for each OPENF% that is opening a  file
     set SECURE.

          The implemented policy is to allow the request based on  whatever
     is contained in the ACCESS.CONTROL file.

          If read, write, or append access is attempted to a file  that  is
     set  secure  and there is no ACCESS.CONTROL file in the same directory
     as the secure file, then access is allowed and the request  is  logged
     as unusual.



     5.2.29  Secure RNAMF% (.GORNF)

          The monitor calls the ACJ for each RNAMF% that is renaming a file
     set  SECURE.   This  function may be called twice:  once for the "old"
     filename, and once for the "new" filename.

          The implemented policy is to allow the request based on  whatever
     is contained in the ACCESS.CONTROL file.

          If rename access is attempted to a file that is  set  secure  and
     there  is  no  ACCESS.CONTROL file in the same directory as the secure
     file, then access is allowed and the request is logged as unusual.
Enhanced Access Control Facility Functional Specification      Page 26


     5.2.30  Set Time (.GOSTD)

          The STAD% JSYS is used to set the system time.

          The policy implemented is to always allow the STAD%  to  succeed.
     This  function  is  primarily  to  assure  an audit trail whenever the
     system date and time is changed.



     5.2.31  SMON% JSYS (.GOSMN)

          The SMON% JSYS is used to set or clear operating system  features
     (such  as  account  validation,  logins  allowed, etc.) and is usually
     invoked with commands in SYSTEM:7-CONFIG and the EXEC's ^ESET command.
     The  Monitor calls the ACJ for each SMON% not done by an enabled WHEEL
     or OPERATOR.

          The policy implemented is to allow SMON% only by enabled WHEEL or
     OPERATOR (the same check that the monitor currently makes).



     5.2.32  Structure Mount (.GOSMT)

          The monitor calls the ACJ for  each  and  every  MSTR%  increment
     mount   count  function  (.MSIMC  function).   Any  job  must  have  a
     "Regulated" file structure mounted in order to use it.

          The implemented policy is to always allow the  increment  of  the
     mount  count  and  let  normal  file  and  directory protection handle
     security.



     5.2.33  SYSGT% JSYS (.GOSGT)

          The SYSGT% monitor call is used to extract information  from  the
     monitor.   The  monitor  calls  us  for  each SYSGT% when the previous
     context is not monitor.

          Note that enabling this function will  cause  a  high  amount  of
     overhead,  and  may degrade system response, so enabling this function
     must be done with caution.

          The implemented policy is to always allow the SYSGT%.



     5.2.34  Terminal Speed (.GOTBR)

          The monitor calls the ACJ for each attempt to set terminal  speed
     using the MTOPR% function .MOSPD.
Enhanced Access Control Facility Functional Specification      Page 27


          The policy implemented is to disallow the MTOPR% unless WHEEL  or
     OPERATOR is enabled.



     5.2.35  TLINK% JSYS (.GOTLK)

          The monitor call used  to  implement  the  EXEC's  ADVISE,  TALK,
     BREAK,  and  REFUSE commands is the TLINK% JSYS.  The monitor calls us
     the ACJ for each TLINK% JSYS when previous mode is  not  monitor  mode
     (the TLINK% is being done inside the monitor).

          The implemented policy is to always allow  the  TLINK%.   If  the
     user is set SPY-ON, the log entry will be marked as "unusual".



     5.2.36  TTMSG% JSYS (.GOTTM)

          The monitor call used to implement the ^ESEND and  SEND  commands
     is  the  TTMSG%  JSYS.  The monitor calls the ACJ for each TTMSG% JSYS
     when the previous mode is not monitor mode (the TTMSG%  is  not  being
     done by the monitor).

          The implemented policy is to only allow enabled WHEEL or OPERATOR
     to do the TTMSG%.



     5.2.37  USER-TEST (400000)

          The GETOK% facility allows user (site specific) functions in  the
     range  400000  to  777777.  In order to provide a example of how these
     functions could be added to this ACJ, the USER-TEST function (function
     400000)   is   implemented.   The  test  of  the  function  is  easily
     accomplished  in  DDT.   The  source  code  contains  information  and
     suggestions on implementation of the site specific GETOK% functions.



     5.3  Sample ACJPROFILE.CMD

          The following is a sample ACJPROFILE.CMD file.  This is the  file
     is written with the WRITE command and read with the TAKE command.

          This example shows the type of changes that can be done from  the
     default settings to provide the site with a access control policy that
     is tailored to the site.   The  ACJPROFILE.CMD  file  should  be  kept
     SECURE as well as ACJDEC.EXE and the ACJ source files.

     ! ACJ 7(126) profile written by SCOTT at 18-Apr-89 14:30:11
     Set ACCESS-LOG-FILE BS:<LOGS>ACCESS-CONTROL.LOG
     Set LOG-FILE-CACHE-SWEEP-INTERVAL 30
     Set PRIME-TIME-BEGIN 07:30
     Set PRIME-TIME-END 18:00
     Set SPY-CHECK-INTERVAL 10
Enhanced Access Control Facility Functional Specification      Page 28


     Set SPY-LOG-DIRECTORY BS:<LOGS>INTRUDER
     Enable ACCESS
     Enable ARPANET-ACCESS NO POLICY
     Enable ASSIGN-DEVICE NO LOG
     Enable ASSIGN-DUE-TO-OPENF NO LOG
     Enable ATTACH-JOB
     Enable CAPABILITIES DENY-DECNET DENY-TCP
     Enable CLASS-ASSIGNMENT DENY-BATCH DENY-PTY
     Enable CLASS-SET-AT-LOGIN NO LOG
     Enable CREATE-DIRECTORY CONSOLE DENY-BATCH DENY-CTY DENY-PTY
     Disable CREATE-FORK
     Enable CREATE-JOB NO POLICY
     Enable CREATE-LOGICAL-NAME DENY-BATCH DENY-DETACHED DENY-PTY
     Enable CTERM
     Enable DECNET-ACCESS NO POLICY
     Disable DETACH
     Disable ENQ-QUOTA
     Enable GET-DIRECTORY
     Disable GETAB
     Enable HSYS DENY-BATCH DENY-DECNET DENY-DETACHED DENY-PTY DENY-TCP
     Disable INFO
     Disable LATOP
     Enable LOGIN
     Enable LOGOUT
     Enable MDDT DENY-BATCH DENY-DETACHED DENY-PTY
     Disable MTA-ACCESS
     Enable SECURE-CHFDB
     Enable SECURE-DELF
     Enable SECURE-OPENF
     Enable SECURE-RNAMF
     Enable SET-TIME
     Enable SMON DENY-BATCH DENY-DETACHED DENY-PTY
     Disable STRUCTURE-MOUNT
     Disable SYSGT
     Enable TERMINAL-SPEED
     Disable TLINK
     Disable TTMSG
     Disable USER-TEST
     User * CLASS-AT-LOGIN 1
     User BATCH-ADMIN CLASS-AT-LOGIN 1 NO LOGIN-CTY NO LOGIN-DECNET -
        NO LOGIN-DETACHED NO LOGIN-LAT NO LOGIN-LOCAL NO LOGIN-PTY -
        NO LOGIN-REMOTE NO LOGIN-TCP
     User CLEMENS CLASS-AT-LOGIN 1 ENABLE-NON-PRIME-TIME
     User CONDOR CLASS-AT-LOGIN 1 SPY-ON
     User EE.* CLASS-AT-LOGIN 2 NO LOGIN-TCP
     User F-S CLASS-AT-LOGIN 1 ENABLE-NON-PRIME-TIME
     User GARKTRON CLASS-AT-LOGIN 1 ENABLE-NON-PRIME-TIME
     User GAS CLASS-AT-LOGIN 1 ENABLE-NON-PRIME-TIME
     User LITTLETON CLASS-AT-LOGIN 1
     User OPERATOR ENABLE-NON-PRIME-TIME NO LOGIN-DECNET NO LOGIN-DETACHED -
        NO LOGIN-REMOTE NO LOGIN-TCP
     User SPITBROOK CLASS-AT-LOGIN 1 NO LOGIN-TCP SPY-ON
     User YAK.* CLASS-AT-LOGIN 2
Enhanced Access Control Facility Functional Specification      Page 29


     5.4  Access Control Log Files

          The access control  log  files  are  an  important  part  of  the
     security provided by the ACJ.  This log file should be reviewed once a
     day to look for unusual activity.  The log file is always made  SECURE
     to  prevent  unauthorized access.  A new generation of the log file is
     created each time the ACJ is run and each night at midnight.



     5.4.1  Log File Format

          The log file is split into pages with a header on each page.  The
     first  line  of  the header contains the ACJ version, system nodename,
     current date time, page number.  The second and third lines  summarize
     the  activity so far:  number of requests allowed, denied, and failed;
     CPU time used;  and "uptime" of the ACJ.

          The log file has been formatted so that each activity results  in
     one  line of text in the log file.  The first item is the time of day.
     The second item is the username requesting the operator (for the LOGIN
     function  the username that is trying to LOGIN will be in this field).
     The  next  field  is  the  access  control  function.   Following  the
     function,  information  about  the  job  is  output.  This information
     consists of the job number, controlling job if job being run on a PTY,
     "batch"  if  a  batch job, terminal number, network origin string if a
     network terminal, and the job's current program  name.   Finally,  the
     enabled capabilities of the process attempting access is output.

          Following that fixed information is a comma and information  that
     is  specific  to this request type.  For example if a user is enabling
     capabilities, the desired capabilities are shown.

          At the end of the line one of three strings may appear.

     1.  "[Denied]"  indicates  that  the  ACJ  denied  the  request.   For
         example,  a user tried to login and isn't allowed to login to that
         terminal type.

     2.  "[Failed]" indicates that the ACJ allowed the request but that the
         action  failed.  For example, a user tried to login and gave a bad
         password.

     3.  "[Unusual]" indicates that the ACJ allowed the request but  it  is
         in  some way unusual.  For example, a user login when that user is
         set SPY-ON.  The conditions under which the request is  considered
         unusual  is  documented in the per-function documentation (section
         5.2.*).
Enhanced Access Control Facility Functional Specification      Page 30


     5.4.2  Log File Examples

          To illustrate the format of the log file, a few examples will  be
     given.  First an example of the header:

          ACJ 7(100) on GARK, Thursday, February 2, 1989 00:00:00, page 1
          Allowed 782 requests, denied 8 requests, 5 requests failed
          Used 1:09.32 in 11:57:56.69

     The header shows that this log file was started at  midnight  and  the
     ACJ has been up about 12 hours, processing 790 requests.

          00:00:47 OPERATOR Open-assign job 194 ctrl 193 TTY233 GALAXY opr
          ana, device PTY7
          00:00:47 OPERATOR Assign job 194 ctrl 193 TTY233 GALAXY opr ana,
          TTY241
          00:00:48 OPERATOR CRJOB job 194 ctrl 193 TTY233 GALAXY opr ana
          00:00:48 SCHMITT Login job 206 batch TTY241 EXEC, by OPERATOR job
          194 ctrl 193 TTY233 GALAXY
          00:00:49 SCHMITT Caps job 206 batch TTY241 ENABLE, desired whl
          00:01:36 OPERATOR Logout job 194 ctrl 193 TTY233 GALAXY opr ana,
          target SCHMITT job 206 batch TTY241 EXEC

     These entries show a batch job  execution.   OPERATOR  running  BATCON
     opened a PTY, assigned it to itself, created a job, which logged in to
     user SCHMITT.  That user enabled capabilities then the batch  job  ran
     to completion.  The job running BATCON than logged out the batch job.

          08:35:49 OPERATOR Cterm job 0 Det SYSJOB, from GIDNEY::SGAGNE
          08:35:55 SGAGNE Login job 214 TTY364 GIDNEY::SGAGNE(CTM) LOGIN

     The next two entries show an incoming  CTERM  connection  from  system
     GIDNEY user SGAGNE, who proceeds to login to this system.

          09:38:48 not-logged-in Attach job 214 TTY444 LAT1(LAT) ATTACH,
          target GAS job 207 Det DETACH [Failed]
          09:38:58 not-logged-in Attach job 214 TTY444 LAT1(LAT) ATTACH,
          target GAS job 207 Det DETACH

     User GAS attempted to attach to his detached job, and apparently typed
     an  incorrect  password  (note  "[Failed]").   On  the  second  try he
     succeeded and attached to his job.

          09:39:32 OPERATOR DECnet job 198 ctrl 193 TTY237 MX opr ana, to
          VAXVLN
          09:47:11 OPERATOR Secure-OPENF job 198 ctrl 193 TTY237 MX opr
          ana, read write PUBLIC:<APUCHRIK>MAIL.TXT.1
          09:49:15 APUCHRIK Secure-OPENF job 199 TTY435 LAT1(LAT) MS, read
          write preserve-dates PUBLIC:<APUCHRIK>MAIL.TXT.1

     The first entry shows the OPERATOR job running MX connecting to system
     VAXVLN  using  DECnet.   The  second entry shows the MX job delivering
     mail to user APUCHRIK, who has a secure  MAIL.TXT.   The  third  entry
     shows this same user accessing his mail file with MS.

          19:17:56 JWONG Terminal-speed job 216 TTY3 EXEC, TTY3 input 2400
Enhanced Access Control Facility Functional Specification      Page 31


          output 2400 [Denied]
          19:38:00 OPERATOR Secure-OPENF job 215 ctrl 206 TTY243 DUMPER opr
          ana, read preserve-dates RANDOM:<RASPUZZI.MAIL>JAN89MAIL.TXT.1
          [Denied]
          19:38:24 OPERATOR Secure-OPENF job 211 ctrl 206 TTY241 DUMPER opr
          ana, read preserve-dates WORK:<DEVANS.POOF>BOBBIE.MAIL.1
          [Unusual]

     The first line shows a user trying to set TTY3's terminal speed.  This
     request  is  denied.   The  second  and third lines show OPERATOR jobs
     running DUMPER to save the system.  The second line  shows  that  user
     RASPUZZI  didn't  allow  OPERATOR  read  access to a file;  the access
     failed and the file is not backed up.  The third  line  shows  that  a
     SECURE  file  was  opened  for reading but there was no ACCESS.CONTROL
     file present in that directory.  The request is marked as unusual  and
     access is allowed.



     5.5  Secure Files and ACCESS.CONTROL

          The implementation of GETOK functions .GOOPN, .GORNF, .GODLF, and
     .GOCFD  allows  the  ACJ  to implement access control of secure files.
     When the monitor calls the ACJ with one of these functions, the policy
     implementation is as follows.



     5.5.1  Secure File Policy Implementation

          The monitor furnishes the ACJ with the filename (and in the  case
     of  .GOOPN  the  desired access).  The ACJ then tries to open the file
     ACCESS.CONTROL in the  same  directory  as  the  file  that  is  being
     accessed.

          If the ACCESS.CONTROL file does not exist or  cannot  be  opened,
     access is allowed and logged as unusual.

          If a match for the file cannot be found in ACCESS.CONTROL,  or  a
     syntax  error  is  detected  while  reading  a line in ACCESS.CONTROL,
     access is denied.

          If the ACCESS.CONTROL file allows access to the secure file, then
     access is granted.

          In any case the attempted access is logged only if  the  function
     (Secure-CHFDB,  Secure-DELF,  Secure-OPENF, or Secure-RNAMF) is set to
     LOG.
Enhanced Access Control Facility Functional Specification      Page 32


     5.5.2  Format of ACCESS.CONTROL

          The format each line of ACCESS.CONTROL is "filename keyword  user
     ...   user,  keyword  user ...  user, ...".  Any combination of spaces
     and/or tabs is allowed as field  delimiters.   Embedded  comments  are
     surrounded  by  exclamation  points,  comment  lines are preceded by a
     semicolon.  A hyphen at the  end  of  the  line  is  the  continuation
     character.

          The filename is the first field on each line.  When  the  ACJ  is
     searching  the  ACCESS.CONTROL  file,  the  first  filename field that
     matches is used.
     Following the filename are access  keywords  followed  by  a  list  of
     usernames.   Each  keyword  and  list  of usernames are separated by a
     comma.  The access keywords are:

      *  ALL (all access)

      *  APPEND (OPENF% append access)

      *  DELETE (DELF%/DELNF% deleting the file)

      *  NOSECURE (CHFDB% clearing FB%SEC)

      *  READ (OPENF% read access)

      *  RENAME (RNAMF% to rename the file from or to filename)

      *  SECURE (CHFDB% setting FB%SEC)

      *  WRITE (OPENF% write access)


          It is assumed that the file ACCESS.CONTROL itself is set  secure.
     If  this  is  not  done,  the file can be changed too easily.  Even if
     access is not granted to the ACJ, it can still read the  file  as  the
     ACJ can always read any file on the system (the job running ACJ is not
     subject to access control).



     5.5.3  Examples of ACCESS.CONTROL Files

          The following example illustrates how user Cloyd has set  up  his
     ACCESS.CONTROL file on his login (PS:) directory.

     !Last edited by Cloyd 20-Dec-88 10:20:33

     ACCESS.CONTROL.* ALL Cloyd,-
             READ Operator, SECURE Operator

     MAIL.TXT.* ALL Cloyd,-
             READ Operator, SECURE Operator, WRITE Operator

     PERSONNEL-REVIEWS.*.* READ Gidney Prospector, ALL Cloyd,-
             READ Operator, SECURE Operator
Enhanced Access Control Facility Functional Specification      Page 33



     *.*.* ALL Cloyd

          The first line in the file is a comment line.

          The second line is for all ACCESS.CONTROL files.   At  this  site
     the Operator username is used to backup files on this system.  Because
     of this, Operator must have READ in order to backup the file  to  tape
     using the DUMPER program.  It is very important to include Operator in
     the list of users that can read all SECURE  files;   if  this  is  not
     included  the files could not be backed up by the nightly Operator job
     that runs DUMPER.  Operator is also allowed to set this  file  secure.
     This  would  happen in case the file structure has been damaged and is
     being restored from tape.  Operator must have SECURE access  in  order
     to  set  this  file  SECURE after it is restored from tape.  Note that
     Operator is not allowed to set the file  NOSECURE  which  could  be  a
     security problem.  The owner is allowed all access.

          The third line is for access to Cloyd's mail file, because  Cloyd
     wants  to keep his mail private.  Again Cloyd has full access, and the
     Operator is allowed to read it and set it SECURE.  Operator  also  has
     to  be  able  to  write the mail file (the job running MX is under the
     Operator user name).

          The next line shows how to use  the  ACCESS.CONTROL  keywords  to
     allow   restricted  access  to  sensitive  files.   Users  Gidney  and
     Prospector are allowed to read the personnel reviews written by Cloyd.
     (Of  course  Cloyd has full access and the usual access for Operator.)
     Not that the use of a hyphen between fields in the  file  indicates  a
     continuation line is to follow.

          The final line of this file is give user Cloyd full access to any
     other  files  that  didn't  match the above filespecs and that are set
     SECURE in this directory.  Without this line, Cloyd would not be  able
     to access any files that were set SECURE.

          To further help  illustrate  the  techniques  involved  in  using
     ACCESS.CONTROL  files, an example of an ACCESS.CONTROL file that might
     be placed in the <SYSTEM> directory on  the  boot  structure  on  this
     system follows.

     !Last edited by STAFF.GREG 10-Dec-88 20:33:10

     ACCESS.CONTROL.*  READ Operator Staff.Mike Staff.Greg,-
                       SECURE Operator Staff.Mike Staff.Greg,-
                       WRITE Staff.Mike Staff.Greg,-
                       RENAME Staff.Mike Staff.Greg

     ACJ.EXE.*  READ Operator Staff.Greg, SECURE Operator Staff.Greg,-
                WRITE Staff.Greg, NOSECURE Staff.Greg

     *.*.*  READ *,-
            WRITE Staff.* Operator,-
            SECURE Staff.* Operator,-
            RENAME Staff.*,-
            ALL Staff.Mike Staff.Greg Staff.Dave
Enhanced Access Control Facility Functional Specification      Page 34


          Users Operator, Staff.Mike, and Staff.Greg are  allowed  to  read
     the  ACCESS.CONTROL  file  and  set  it  secure.  Users Staff.Greg and
     Staff.Mike have WRITE and RENAME access.  If the  ALL  access  is  not
     being  used,  WRITE and RENAME access is often used.  If a text editor
     is used to edit the file, RENAME access is usually required since  the
     text  editor may rename a temporary file to the new version, or it may
     rename the old version to a backup file.

          The file ACJ.EXE can be read and set secure  by  Operator;   only
     STAFF.GREG  may write the file or set it NO SECURE.  Therefore the ACJ
     will disallow any attempts to delete or rename ACJ.EXE.*

          All other secure files in this directory can be  read  by  anyone
     (given  that  the directory and file protections allow this);  written
     by Staff.* and Operator;  renamed by Staff.*;   and  renamed,  deleted
     and SET [NO] SECURE by Staff.Mike, Staff.Greg, or Staff.Dave only.



     6.0  Services Required

          The services required only include  (1)  the  RCVOK%  and  GIVOK%
     monitor  calls  and  (2)  the  .SFSOK functions of the SMON% and TMON%
     monitor calls.

          In order to enjoy all features implemented in this  program,  the
     running  monitor  must  include  the edits associated with the TOPS-20
     Security Enhancement project.

          The ACJ is written to be able to gracefully handle monitors which
     do  not have the newer GETOK functions included (those that are a part
     of the TOPS-20 Security Enhancements).  In this manner the ACJ may  be
     run  on  earlier  monitors.   However  older monitor testing will only
     occur on 7.0 autopatch 20  TOPS-20.   Older  monitors  (7.0  prior  to
     autopatch  20, 6.1, 6.0, 5.1, and 4.1 monitors) will not be tested but
     can be expected to work.



     7.0  Major Algorithms

          The profile generation sets up tables in low memory.  The profile
     generation  code  and  all program symbols are placed in the program's
     high segment (starting at 400000 octal).  All of  the  access  control
     code and common subroutines are kept in low memory.

          The profile generation phase is implemented  using  the  standard
     COMND% JSYS interface.  When the profile generation phase is complete,
     the SAVE command is used to create  a  runnable  ACJ.   Only  the  low
     segment is saved, so that no program symbols or commands to change the
     profile or policy are saved with the runnable ACJ.

          The access control program contains an initialization section  to
     perform  TMON%  and  SMON%  functions to set the fork up as the system
     access control facility.
Enhanced Access Control Facility Functional Specification      Page 35


          A main loop is then entered, which performs the following steps.

     1.  Storage that needs to be cleared on each request is zeroed.

     2.  A RCVOK% is done to read one request from the  monitor.   The  ACJ
         blocks  in  the  RCVOK% until a there is a function to read in the
         GETOK request queue.

     3.  A internal table of enabled functions  is  searched  to  find  the
         offset in the per-function tables.

     4.  A internal table of user profiles is then  searched  to  find  any
         special user profile bits.

     5.  A function specific logging routine is called to create  a  string
         to be sent to the log file.

     6.  A function specific policy routine and a  general  policy  routine
         are  called  to  determine  if  the  function should be allowed or
         denied.  If the function should be denied a bit is  lit.   If  the
         function should be unusual a bit is lit.

     7.  Using this information a GIVOK% is done.

     8.  A common routine is called in case the ACJ needs to wait to see if
         the function failed.  If the function failed, a bit is lit.

     9.  A common routine is called to append  "[Denied]",  "[Failed]",  or
         "[Unusual]"  to the logging string and then this string is sent to
         the terminal or log file as  specified  by  the  function  profile
         bits.

    10.  If the log file needs to be closed and reopened, this is done.

    11.  Loop for more requests.


          Upon a ACJ crash all functions that were enabled are disabled, an
     ACJ  crash  dump  is  taken, and the program halts (see Error Handling
     section for more details).



     8.0  Performance Expectations

          The new ACJ will be coded in such a way as to  provide  the  best
     performance  possible.   However,  there are no particular performance
     expectations or goals.
Enhanced Access Control Facility Functional Specification      Page 36


     9.0  Error Handling

          All monitor calls that fail where failure is significant  to  the
     ACJ  will  be handled using the JSERRO macro or the OJSERR macro.  The
     JSERRO macro dispatches with  a  ERJMP  or  ERCAL  (depending  on  its
     arguments) and OJSERR dispatches with CALL (PUSHJ P,).  Each error (in
     either profile or policy phases) will be printed  on  the  controlling
     terminal.   Each error when running as the policy program will also be
     written to the log file.

          Errors caused by the ACJ attempting to use GETOK  functions  that
     are  not  yet  implemented  will be gracefully handled (i.e.  no error
     messages will be printed and the particular function will just not  be
     used).

          Errors while writing to the log file will cause the log  file  to
     be  closed.   A  new  log file will then be opened.  If a new log file
     cannot be opened, a message will be printed on the console.  Each time
     there is something to log and no log file is open, a new log file will
     be attempted.

          Serious errors in the ACJ (e.g.  RCVOK% and  GIVOK%  errors)  are
     handled with the "BUG" macro.  This macro will cause the ACJ to crash.
     The ACJ crash routine (called BUGHLT) will save all  of  the  ACs  and
     last  TOPS-20  error  code,  disable all enabled GETOK functions, then
     write a ACJ crash dump and halt.  The filename of  the  dump  will  be
     "DMP:ACJ-edit-code-CRASH.EXE", where "edit" is the ACJ edit number and
     "code" is the ACJ crash code given in the BUG macro.  This  ACJ  crash
     dump  may be examined to determine the cause of the problem.  Since no
     symbols will be present, FILDDT must be used to  get  symbols  from  a
     matching ACJDEC.EXE.



     10.0  Diagnostic Features

          Diagnostic features will be limited to the ACJ  crash  dumps  and
     error messages described in the previous section.



     11.0  Documentation Impact

          There is no documentation impact from this project.



     12.0  Constraints and Tradeoffs

          Since this program is not overly complex and  its  debugging  can
     easily be accomplished, no design specification will be written.

          It is clear that not all customers  will  be  able  to  use  this
     program  without  modification  unless  each  step  in  the program is
     controllable in the policy setting phase.  This would make the program
     much  more  complicated and needlessly complex.  It is hoped that only
Enhanced Access Control Facility Functional Specification      Page 37


     minor modifications would be needed at  any  customer  site  and  that
     these modifications would only take place in the ACJUSR module.

          There are no significant risks associated with this project.



     13.0  Packaging/Building/Installation

          The source files will be supplied to the customer base using  the
     Autopatch process.  A .CTL file will be furnished which will build the
     EXE file from the source .MAC files.
Enhanced Access Control Facility Functional Specification      Page 38


     14.0  Revision History



     Date       Rev  Author       Description
     ----       ---  ------       -----------
     30-Nov-88   1   GScott       Creation
      5-Dec-88   2   GScott       Comments from developers
      7-Dec-88   3   GScott       Add new commands and functions
     20-Dec-88   4   GScott       Adding new keywords and fix mistakes
     28-Dec-88   5   GScott       Add new operation of GOCFD and GOOPN
      6-Jan-89   6   GScott       Include edits in ACJ 7(55)
     12-Jan-89   7   GScott       Add clarification on several GETOK functions
     26-Jan-89  10   GScott       Add user function and slight cleanup
      2-Feb-89  11   GScott       Add NOSECURE
      6-Feb-89  12   GScott       Add special CHFDB cases
      4-Apr-89  13   GScott       Add changes from edits 106-124
     18-Apr-89  14   GScott       Add changes from edits 125 and 126
     25-May-89  15   GScott       Add changes from edits 127 and 130