Device Protection in the Epicure Control System
Edward Dambik, Frank Nagy, Therese Watts, Robert West
.5cm
This update of the Protection Design Document, merely changes the number of
[
]
bits allocated for the domains and device-classes in the 128 bit authorization string.
This change was made when it was astutely pointed out that the number of Exxx device-class
entries has the potential of being quite large. This is the only change over Design Note
72.0 which you all should have received around February 7th.
[
]
The protection scheme to be provided within the Epicure system attempts to provide a flexible, but consistent scheme of device protection, with a minimum impact on performance. The following describes this scheme and is based on the `Proposal for Device Protection in the EPICURE Control System' authored by T. Lahey and R. West, September 2, 1988.
Device Database Protection Attributes
A READ__PROT attribute and/or a WRITE__PROT attribute may exist for each of the basic properties READING, SETTING, STATUS, CONTROL, READING__ALARM, and STATUS__ALARM of a single device. If a property of a device does not have an xPROT attribute, then that device-property combination is not protected, which is usually true for properties such as READING and STATUS.
The READ__PROT and WRITE__PROT attributes are simply a string of 128 bits.
Each of these bits is defined to represent either a specific area of a beam line,
such as `Proton West (PW)', or a specific classification of a device such as
`primary power supply'.
[
]
The 32 msb's represent beam line areas which will heretofore
be referred to as `domains', and the remaining 96 lsb's represent device classifications
which will heretofore be referred to as `device-classes'.
[
]
Each of the protection attributes defined for a device therefore will consist of some subset of domain and device-class bits.
The following is the list of domains currently defined:
The following is the list of device-classes currently defined:
A file named xxxxx, which contains the lists of valid domains and device-classes and their corresponding bits, will be stored in the central database file area of node Disney. This is the file that must be used to obtain the valid domain and device-class lists and their corresponding bit definitions.
Privileges Database
The privileges database is used to administer the access that each of the users and controlled programs, within the Epicure system, has to devices. A user is a person who has a VMS account, and a controlled program is a program which resides in a system controlled area. A 40 character string which is space filled to the right of the name, is reserved to hold the identification of users and controlled programs. Only authorized privilege database managers can alter the privileges accorded to a given user or program. Privilege database managers are authorized by Access Control Lists (ACL's) within VMS.
The privileges database information while changeable, is viewed to be somewhat static. That is, once information is setup for a user or program, it is likely to stay the same for weeks or months at a time. Privileges which are only accorded temporarily, will not be managed by this mechanism. The mechanism for issuing temporary privileges will be described later.
User or program privileges are specified by a single 128 bit string, whose bits are defined in the xxxxx file specified above. That is, the actual bit string structure that defines the domain and device-class definition of a device property is also used to define the domain and device-class privileges of a user or program.
For a user or program to be able to access a protected device, the protection characteristics of the device must be a subset of the users or programs privileges. That is, the user or program must be authorized for some domain to which the device property belongs, and the user or program must be authorized for some device-class to which the device property belongs. If this is not the case, a privilege violation results.
A user or program will consequently have access to all device-classes specified for all the domains specified in this authorization file.
The privilege database will provide a quadword date and timestamp field, and a 32 character privilege database manager identifier field, with every user and program authorization record. It is required that the privileges database editor update these fields everytime any change is made that effects domain or device-class privileges of an authorization record. This field is first timestamped when a authorization record is added to the privilege database. This information will allow a utility program to audit privilege authorizations.
The privilege database will provide a 32 bit flag which will provide hooks for extended services. This hook could, for instance, be used to disable a user who may be leaving an experiment for a number of months and then upon returning re-enable the user with old privileges intact, or it could be used to accord super-user privileges to those who oversee the system.
In summary, an authorization record consists of:
Privileges Database Editor
The privileges database editor is a screen oriented editor that enables the privilege database managers to quickly and simply add or change the domain and device-class privileges of a given user or program.
One way in which the privileges database editor simplifies the job, is by presenting the privileges database manager with a set of shorthand privilege designators which represent `the or of domains' or `the or of device-classes'.
Each time a new user or program is added to the authorization list, or a domain or device-class list is changed for an authorization record, the privilege database editor will record the date and time, and the name of the privilege manager in the changed authorization record.
A delete of a user or program, within the privileges database editor, results in both the deletion of this authorization record from the privileges database and an entry in a special dead user log. The dead user log should contain the same information as an authorization record, including the privilege manager that made the deletion and the time the deletion was made. This log can be written out as a text file which would then be periodically put to hardcopy prior to automatic deletion by the system at some periodic time interval.
The following is the list of privileges designators currently defined:
Domain designators
Device-Class designators
Implementation
When the DAR process is initialized (call to DA_init), DAR will capture the identification of the user or program. When the DAR process starts to build a new data acquisition list, (call to DA_process or DS_process), the privileges database information is accessed for this user or program. When a device entry is inserted into the list, the device's protection information is accessed and checked against the user's or programs's privilege information. Only programs that have been system installed are allowed to have protection privileges. When the requestor is a program, DAR verifies that the program is indeed a valid system installed program.
No user/program privileges or device protection information is retained by the DAR process after execution of the list is started. If either device protection or user/program privilege information is edited, the changes will not affect any data acquisition lists which are already executing. Such lists must be terminated and then restarted. For example, the privilege/protection information for a page display can be updated by simply placing the cursor after the name of the page file and entering carriage-return, causing the data acquisiton list to be rebuilt. Manual intervention is required to obtain the new information due to the potentially large amount of time required to notify all DAR processes affected by a change in privilege and/or protection, and the management headaches of knowing where all the DARs may be running at any given time.
Temporary Device Access Privileges
In addition to the actual privileges database, Dar will retain, in its private virtual memory, a special list which is used to manage temporary privilege assignments. Only users are allowed temporary privileges. Temporary privileges are never accorded to programs.
In order to issue a temporary privilege, the privileges manager must login to the node where the privilege is to be granted. Temporary device privileges are therefore restricted to RDCS nodes.
If DAR fails to find an entry for a user in the privileges database, or if DAR fails to authorize a request for a user, DAR will check its list of temporary assignments. The information retained consists of the 32 character user id, a list of `Device Index, Property Index pairs' (DI-PI's) for which this user is authorized, and a 64 bit expiration timestamp. There may be multiple lists of this type for a single user, each with a different expiration timestamp. Timestamps cannot be extended. If the privilege expires, it must be reinstated for another time interval.
DAR checks the current time against the expiration timestamps. When the current time exceeds an expiration timestamp, DAR will remove the expired list from its temporary privilege list.
A special edit program will be provided on every RDCS node that can run DAR. This edit program will provide for the creation of temporary user privileges. The privileges manager must login to the node on which the temporary user will be given privilege to run, and issue the privileges here. The privileges will then be in effect only at this node.
This means that each Data Acquisiton Requestor (DAR) process keeps in memory, its own version of this list. No record of this list remains if the DAR process or the VAX node crashes. The list is always initialized as empty when the DAR process starts up. If the system is restarted for any reason, temporary users will upon restart lose their privileges and have to ask to have them reinstated.
DAR will receive the temporary user lists via its mailbox. Temporary privileges can only be added. If a privilege manager wishes to cancel a temporary privilege, this can only be done by stopping and restarting the DAR process. However, this action will delete all temporary users on this node.
A single central file will be retained that keeps a record of all temporary privileges accorded. This file will contain the node on which the privilege was granted, the user identification, the di-pi list, the expiration time, and the privilege manager that issued the privileges. This file will be periodically put to hardcopy and then deleted. The editor used to add a temporary entry to DAR private memory, must also provide this information to the central file. This file will be kept in a text format.
Should temporary privileges be abused, the users of the epicure system will suffer performance degradation. This mechanism is meant for the exceptional case, and is not to be used as the norm of operation. The duration of time for which a temporary privilege is issued should be small, and the di-pi device list should likewise be very limited. At any given time, there should be few, if any, of these sorts of users! The maximum duration, for which a temporary privilege should ever be given, is a single shift.
Utilities
Access is available to a utility program which allows screen display and hardcopy display of device protection information. This utility program can access privilege information from:
This utility program will allow a set of domains and/or device-classes to be specified, and produce a list of all users which have access to devices belonging to the set defined. Optionally, this listing can be requested to contain the date and timestamp at which these privileges were last updated along with the privilege database managers name.
This utility program will provide a list of all or select users to be displayed along with their authorized domain and device-class lists. Optionally, this listing can be requested to contain the date and timestamp at which these privileges were last updated along with the privilege database managers name.
This utility program will allow a set of domains and/or device-classes to be specified, and produce a list of all devices which are members of the specified domain and device-class.
No special utility will be provided for the temporary privilege information, but the central temporary user file will be made readily available for viewing and printing on demand.
Examples
The following scenarios are examples to help one see how this tool can be used.
Keywords: Epicure, database, devices, protection
Distribution:
