Safe and Secure
Tighten up VS system security with this tip
From "VS Workshop", Access to Wang, November 1990
|[ Prior Article ] [ Return to the Catalog of articles ] [ Next Article ]|
An irony of systems professionals is that they are often poor at using the informational tools of their craft for their own administrative needs. Most of us revert to scribbled notes on binder paper when there are tools all around us that could simplify the organization and access of information.
VS systems administration is an example of a task where fast access to critical information can mean life or death to the system. The tools provided by the operating system for the system configuration, network configuration, hardware management, and security aspects of systems administration are inadequate for careful management without supplemental tools specific to your needs. Fortunately, Wang also provides means for easily extending operating system functions through the File Management Utilities, Procedure language, system subroutines, and other tools.
This month I will present the Security Data Base - an approach for analyzing system security from any number of perspectives. In keeping with my theme of universal access and simplicity, the Wang CONTROL and INQUIRY utilities are used. For those new to the VS or security, this project is an ideal way to meet the Wang File Management Utilities.
The Security Data Base process began when I needed to know which users on the system had access to a given file class. The SECURITY utility showed individual user access, but did not allow me to review access across the organization. The SECURITY listing presented a better view, but the file access information was buried in a 24-character report field - one position for each letter of the alphabet. The chance of overlooking valid information was too great, so I set out to get a better view of the data.
The SECURITY listing showed all of the information I needed, so I decided to use it as the data for my process. I constructed a CONTROL file (SECUREDB; see Figure 1) to describe the listing file and the positions of most of its fields. The fields include user identification, file access profile, start procedure, HELP and Operator mode options, and the number of times the logon ID can be used simultaneously. (There may be minor differences between this listing format and that of other operating systems. Verify field locations with a forms ruler if you are unsure if your listing format is the same.)
The file access profile is presented in two forms: the ACCESS field shows the entire 26-character profile, while the individual access items (ACCA, ACCB, etc.) show file access for each of the 26 items. Each position can be one of four values:
Character Meaning "." (period) No access to the file class "E" (EXECUTE) The user can only run the file "R" (READ) The user can run the file or read it "W" (WRITE) The user can run, read, or write (modify) the file
With the CONTROL file built and a listing from the SECURITY listing ready, I was ready to answer my file access question. I ran INQUIRY and entered the following query:
LIST USERID NAME ACCESSWHEN ACCG GT "."AND MAXLOG GE 1
Translated, this means List the user's initials, name, and access profile when they have access to class G files and can log on at least once. (The MAXLOG selection is present so that INQUIRY will bypass headers and other unnecessary lines in the print file.) Few things in life are as satisfying as watching a correctly- specified query delivering the exact results you need!
Other uses for SECUREDB came to mind almost immediately:
List all System Security Administrators
LIST USERID NAME WHEN SAIND = "Y" AND MAXLOG GE 1
List users with logon procedure START
LIST USERID NAME WHEN LOGFILE = "START " AND MAXLOG GE 1
List all user IDs that can be used more than once
LIST USERID NAME WHEN MAXLOG GT 1
List all users with operator privileges
LIST USERID NAME WHEN OPER = "Y" AND MAXLOG GE 1
After the process was defined, I created the SECURE procedure (see Figure 2) to simplify the query process. SECURE runs INQUIRY, entering the library and volume of the print file. As written, this procedure assumes that you have run SECURITY to get the listing, renamed the print file to SECUREDB and have a CONTROL file named SECUREDB in your personal CONTROL file library; modify the procedure as needed to change these assumptions.
A curious aspect of the SECURITY utility is that you cannot run it from a procedure to get a listing. In fact, there appears to be no standard GETPARM for the listing file, so you can't even intercept the file name. (There is a CORRECTION GETPARM named PRINTOUT, but Procedure cannot control the CORRECTION GETPARMs.) If you have a way around this limitation, please let me know.
Figure 1: CONTROL file SECUREDB
Parameter Value Record size 134 maximum; compressed File organization Consecutive
Field Name Position Length Comment USERID 4 3 3-character user ID NAME 17 24 Full user name SAIND 42 1 Security Administrator (Y/N) ACCESS 44 24 File access mask (A - Z) ACCA 44 1 Access for A ACCB 45 1 Access for B ACCC 46 1 Access for C (repeat for all letters) ACCX 67 1 Access for X ACCY 68 1 Access for Y ACCZ 69 1 Access for Z LOGFILE 71 8 Logon file LOGLIB 80 8 Logon library LOGVOL 89 6 Logon volume HELP 98 1 Help disabled (Y/N) OPER 102 1 Operator privileges (Y/N) MAXLOG 109 3 Maximum logons
Figure 2: Procedure to Create SECUREDB Listing Using INQUIRY
PROCEDURE SECURE - uses SECURITY listing as data DECLARE &SPOOLIB STRING (08) DECLARE &SPOOLVOL STRING (06) EXTRACT &SPOOLIB = SPOOLIB, &SPOOLVOL = SPOOLVOL RUN INQUIRY DISPLAY INPUT FILE = SECUREDB, LIBRARY = &SPOOLIB, VOLUME = &SPOOLVOL, MODE = INPUT, OPTION = DISPLAY, CHANGE = NO ENTER CONTROL ENTER QUERY TITLE = "SECURITY ACCESS LISTING", LINE1A = "LIST USERID NAME SAIND ACCESS HELP OPER", LINE3A = "WHEN MAXLOG GT 0", DISPLAY = YES RETURN
Copyright © 1990 Dennis S. Barnes
Reprints of this article are permitted without notification if the source of the information is clearly identified