Protected subsystem
A protected subsystem is an application that, when run, causes the process running the application to be granted one or more rights identifiers. For as long as a user runs the subsystem, the user's process rights list carries these additional identifiers; when the user exits the application, the identifiers are removed. The use of protected subsystems allows a system manager to avoid granting excessive privileges to users. Protected subsystems use subsystem ACEs.
Contents
How Protected Subsystems Work
In a protected subsystem, an application protected by normal access controls serves as a gatekeeper to objects belonging to the subsystem. Users have no access to the subsystem's objects unless they execute the application serving as gatekeeper. Once users run the application, their process rights list acquires identifiers giving them access to objects owned by the subsystem. As soon as they exit from the application, these identifiers and, therefore, the users' access rights to objects are taken away. Subsystem identifiers are not propagated by default when subprocesses are spawned.
Users with execute access to the application gain access to the subsystem. Once in the subsystem, users can work with the data files and other resources of the subsystem. A subsystem can have several identifiers because the resources consumed by the subsystem (the files, printers, and so forth) can be protected differently. Possession of subsystem identifiers is limited to the period users are executing the application. Once the users exit from the application, the identifiers are removed from their process rights lists. Subsystem identifiers are also removed from the rights list whenever users enter a Ctrl/Y sequence or attempt to create a subprocess with the DCL command SPAWN. (In this respect, use of the subsystem identifiers is identical to the operation of images installed with privileges.)
Advantages of Protected Subsystems
Using protected subsystems offers several advantages:
- It is a mechanism to provide conditional access to data that is not available with traditional OpenVMS access controls.
- It requires less skill than installing images with privilege. Writing a secure privileged image requires skill, and failures can compromise system security.
- It is an alternative to creating protected shareable images (also called user-written system services).
- Unprivileged users can manage protected subsystems without much assistance from the system manager.
Uses of Protected Subsystems
The OpenVMS Guide to System Security lists the following examples of using protected subsystems:
- A group membership list available to all group members that contains personal data. In a protected subsystem, all members of the group can read selected information and update specific types of information.
- An application that filters out sensitive data sent to printers so that confidential files would be sent to printers in restricted areas while public files would be sent to any available printer.
Security Subsystem Identifiers
The following identifiers are reserved for use in the security subsystem and should not be granted to any user:
- SECSRV$CLIENT
- SECSRV$COMMUNICATION
- SECSRV$OBJECT
Designing Protected Subsystems
Subsystem designers need to generate a list of identifiers that are necessary for it to operate as intended. The system manager will then create these and other identifiers and grant the subsystem identifier to the subsystem manager. Someone developing an application for a protected subsystem must link the application images without the /DEBUG or /TRACEBACK qualifiers.
Installing Protected Subsystems
Although this kind of subsystem often precludes the need for privilege, applications can be installed with privilege. For example, some applications may need the PRMGBL privilege to create permanent global sections, or they may need the AUDIT privilege to send security audit records to the system security audit log file. Installation of a protected subsystem application with privileges in the All category is not recommended.
Protected Subsystem Managers
Protected subsystem managers are users who assign the subsystem identifier to the images that make up the subsystem. If unprivileged, they need to be granted the subsystem identifier and control access to the protected objects in the subsystem. Managers of the subsystem can restrict access to objects of the subsystem in the following ways:
- create special identifiers for resources belonging to the subsystem that they do not want all members to access and add ACEs to these resources.
- use compound expressions in ACEs and thus grant access conditionally.
Creating a Protected Subsystem
1. Add a Subsystem ACE containing the subsystem identifier to the ACLs of the application images. A Subsystem ACE has the following format:
(SUBSYSTEM,{IDENTIFIER=identifier[,ATTRIBUTES=attributes]})
2. Add an Identifier ACE to the ACLs of the various objects belonging to the subsystem. Each Identifier ACE contains one of the subsystem identifiers in the following format:
(IDENTIFIER=identifier, ACCESS=access-type[+...])
3. Mount the disk countaining the application images and the protected objects with the /SUBSYSTEM qualifier - you need the SECURITY privilege to do this. You can turn the processing of Subsystem ACEs on and off dynamically with the DCL command SET VOLUME /SUBSYSTEM. This command is especially useful for the system disk, which is not mounted using the MOUNT command. Any person mounting a subsystem is responsible for knowing what is on the volume being mounted. Without this knowledge, an operator or system manager can inadvertently subvert system security. For example, it is easy for a user with privileges on one cluster to put an application holding a subsystem identifier on a volume and then take the volume to a naive operator on another cluster and request that it be mounted. Because the application holds an appropriate subsystem identifier, it feigns membership in a subsystem for which it is unauthorized. Therefore, mount volumes of only those users whom you trust, or thoroughly search a volume for Subsystem ACEs before you mount it with subsystems enabled.
