Trailing-Edge
-
PDP-10 Archives
-
bb-kl11l-bm_tops20_v7_0_tsu03_2_of_3
-
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