| Spreadsheet Connective | Index Level | T-verify error message explanations |
| Syntax | |
| Category | Article |
| Type | Article |
| Description |
Discusses system security.
Contributed by Chris Alvarez. Original Article ran in PickWorld Magazine. This article assumes a working knowledge of the system file structure and design. One common misconception about the Pick System is that system security does not exist. While the security features available in Pick are not as extensive as those available in most Unix releases, it is possible for a System Administrator to configure a security system that is effective for most installations. Unlike R83, D3 employs the concept of a USERS file. This file contains a description for each user permitted to logon to the system and enables the System Administrator to control the system at both the user and account levels. A separate user item should be added to the USERS file for each authorized user of the machine. For assistance in creating entries into the user file, please reference page 313 of the Pick Systems Reference Manual or consult Technical Bulletin #T28. The file contains several attributes of interest to this discussion including the KEYS, PASSWORD, OPTIONS and PRIVILEGE attributes. The password for the user is probably the most important part of the security system because most of the security measures available are based upon the information found in the USERS file. Each user should be issued a password and those passwords should be changed on a regular basis. Care should always be taken to ensure that a user's password is not shared with other users. It is possible to multi-value the password attribute to facilitate multiple passwords for one user. While this is not recommended for the user, it is useful when used on the account to allow a master password for the System Administrator. Make sure each user in the USERS file is assigned a password, including those received with the original release. For exam ple, the user '?' was shipped on some earlier releases of Advanced Pick as a way of entering new users but provided a 'backdoor' into any secured system. Each account found on the system should also be assigned a password, including the system accounts shipped with the original product. This list should include any entries in the "mds" file that are q-pointers to other accounts. Multiple passwords may be assigned to any account to facilitate the ability to create several password layers. This is accomplished by multi-valuing the password attribute in the account item found in the "mds" file. The next step in securing the system is to limit what areas the user is allowed to access. This is done in three ways. First, the administrator can limit the system resources available to the user through the use of system privileges secondly, the administrator can limit access to TCL and thirdly, the administrator can limit which files the user is able to use through the use of update and retrieval locks. System privileges can be set to one of three levels ranging from SYS0 to SYS2, with SYS2 as the highest level. In most installations it is a common practice to set the privilege level for each user to the highest setting because of a lack of understanding of the feature. Only those users that help in the administration of a system should be assigned SYS2 privileges, while most users should be assigned SYS1 privileges. Unfortunately, the exact list of features available to each system privilege level is not available. (ed. note: see "system privileges" for a complete list.) What is known is that SYS0 privileges exclude usage of all peripheral devices and system functions. This includes the use of the TCL verbs CLEAR-FILE, DELETE-FILE and CREATE-FILE. Users with SYS1 privileges will be able to access peripheral devices and some system functions. The biggest reason for setting the majority of users to either SYS0 or SYS1 privilege level is that neither has full access to the system debugger. A user can easily be denied from using TCL by placing the character 'r' in the options attribute, which is attribute 9, of their item in the users file. In this manner, the administrator can limit the number of users with access to TCL commands. When a user with this restriction tries to get to TCL either through level pushing or the use of the break key, the user will be returned to the original logon program for the current account. The file-defining item (d-pointer) of a file contains two fields for lock codes to limit a user's access to a file unless the user item contains matching codes. Although these facilitates exist in R83, they have been enhanced in D3 to include multi-value codes. There are two types of locks, update and retrieval. When an update lock is placed on a file, only those users with matching lock codes in their user item will be allowed to make updates to the file, but any user will be able to view the items in the file. Conversely, the retrieval lock limits the viewing of items in the file. The lock codes can be any character string, but it is suggested to limit them to something simple, such as the name of the file. For example, if the System Administrator wanted to limit the access to the customer file, the word 'customer' could be placed as the update lock on the file-defining item for the customer file. Only those users with the word 'customer' found in the list of keys on their user item would be allowed to update the file. Using this system, the administrator would place the name of the file on the file-defining item for each file needing protection. The KEYS attribute of each user item in the user file should be multi-valued with each file name the user is allowed to access. One last step can be taken to track the updates of a sensitive file. It is possible to call a FlashBASIC program anytime something is changed in a file, regardless of the process used to make the change. This includes updates from tape, FlashBASIC and any editor. Place a CALLX on attribute 8 of the file-defining item for the data section of the file using the following syntax: CALLX PROGRAM Where PROGRAM is any cataloged FlashBASIC subroutine with one argument passed to the subroutine. The following subroutine is an example of an audit program to keep track of which user changes a file. A caution about using this or any auditing program: Pick Systems receives numerous calls each week from customer's complaining their machine has ground to a standstill over the past months. The support department usually discovers that the customer's application contains a program that writes auditing or history information to a history file. When the application was installed, the file is usually sized at well below the needed level and becomes incredibly fragmented over time. The fragmentation will slow the system down and can only be remedied by using a file resizing program against the data base, followed by a full system restore. The subroutine below will create a data level file called AUDIT with a default modulo of 3. If the file being audited receives numerous transactions, please change the modulo as necessary. audit 001 subroutine audit(new.item) 002 * Subroutine to create an audit trail for any file. 003 * 16 October 1991 CJA 004 * 005 * To use: 006 * 007 * This program can be used to keep a complete audit trail of 008 * changes made to any data or dictionary section of any file. 009 * On any file d-pointer, a CALLX calls this program at file 010 * time using the following syntax as the correlative: 011 * 012 * CALLX AUDIT 013 * 014 * To audit the dictionary section of a file, place the 015 * CALLX on the d-pointer for the file found in the master 016 * dictionary. For the data section, place the CALLX syntax 017 * on the d-pointer for the data section in the dictionary 018 * of the file. 019 * 020 * When an item is filed into the file, an audit record will be 021 * written to a data file called AUDIT. If this file does not 022 * exist, the program creates the file. The audit record will 023 * include only lines which have been changed and are stored 024 * in the following format: 025 * 026 * 001 OLD.DATA]NEW.DATA 027 * 002 OLD.DATA]NEW.DATA 028 * . 029 * . 030 * . 031 * NNN OLD.DATA]NEW.DATA 032 * 033 * The item-id includes the original item's item-id 034 * concatenated with the user id and the timedate the item was 035 * changed and looks as follows: 036 * 037 * item-id*user*timedate 038 * 039 * The audit file is created with a default modulo 040 * of 3. Depending on activity in the file, this audit 041 * file could become badly sized and cause speed degradation. 042 * 043 equate am to char(254) 044 equate vm to char(253) 045 * 046 * Open file and retrieve old.item for comparison to new.item. 047 * 048 file.name = access(11) 049 item.name = access(10) 050 open file.name to f.file 051 read old.item from f.file,item.name else old.item = '' 052 * 053 * Verify existence of audit data level file by creating file 054 * 055 execute 'create-file data ':file.name:',audit 3' capturing trash 056 * 057 * Find the differences between the old.item and the new.item and build 058 * audit record. If no differences exist then do not build audit record. 059 * 060 audit.record = '' 061 no.lines = dcount(old.item,am) 062 for line = 1 to no.lines 063 if old.item<line> # new.item<line> then 064 audit.record<-1> = line:vm:old.item<line>:vm:new.item<line> 065 end 066 next line 067 * 068 * Write audit record if item has changed. 069 * 070 if audit.record # '' then 071 user = field(oconv('','u50bb'),' ',2) 072 item.id = item.name:'*':user:'*':time():date() 073 open file.name:',audit' to f.audit 074 write audit.record on f.audit,item.id 075 end 076 return |
| Options | |
| See Also | |
| Example | |
| Warnings | |
| Compatibility | D3 7.0 AP |
| Spreadsheet Connective | Index Level | T-verify error message explanations |