HP OpenVMS Systems Documentation
OpenVMS Guide to System Security
22.214.171.124 Subsystem Attribute
You can authorize users to manage protected subsystems by granting them a subsystem identifier with the Subsystem attribute. This empowers users to enable images to access the objects managed by the subsystem. (See Chapter 13 for a discussion of protected subsystems.)
In the following example, user Schwartz is given the authority to create a subsystem with the identifier MAIL_SUBSYSTEM. Schwartz is also given control access to the application image to set access controls.
8.6.8 Modifying a System or Process Rights List
As a privileged security administrator, you can use the SET RIGHTS_LIST command to modify the rights list of any process on the system or to modify identifiers in the system rights list. Adding an identifier to the system rights list effectively grants it to all users. You can also use the SET RIGHTS_LIST command to add attributes to existing identifiers.
A possible use of the system rights list is to enable site-specific environmental conditions. For example, a batch job scheduled to run at 8:00 a.m. could add the following identifier:
Another batch job scheduled for 5:00 p.m. could remove the identifier DAY_SHIFT:
The effect is to enable access to protected objects with the identifier DAY_SHIFT during the 8:00 a.m. to 5:00 p.m. period.
The command in the next example modifies a process rights list by adding the SALES identifier to the rights list of the process DEDNAM. Specifying the Resource attribute allows the holders of the SALES identifier to charge disk space to it.
8.7 Giving Users Privileges
Some system activities are limited to users who hold specific privileges. These restrictions protect the integrity of the operating system's performance and, thus, the integrity of service provided to users. Grant privileges to each user on the basis of two factors: (a) whether the user has a legitimate need for the privilege and (b) whether the user has the skill and experience to use the privilege without disrupting the system.
A user's privileges are recorded in the user's UAF record in two privilege vectors. One vector stores the authorized privileges, and the other vector stores the default privileges. The default privileges are the subset of authorized privileges that a user process receives at login.
When a user logs in to the system, the user's privilege vector is stored in the header of the user's process. In this way, the user's privileges are passed on to the process created for the user. Users can use the DCL command SET PROCESS/PRIVILEGES to enable and disable privileges for which they are authorized.
The operating system monitors and audits the use of privilege. You can
enable auditing for specific privileges and examine the audit log file
to see what privileges were used to execute DCL commands or system
services. See Chapter 9 for further information.
Privileges are divided into the following seven categories according to the damage that the user possessing them could cause the system:
Table 8-2 categorizes the privileges and includes a brief definition of the powers associated with each privilege.
8.7.2 Suggested Privilege Allocations
Appendix A lists all user privileges and includes recommendations on when to grant them. When allocating user privileges, be conservative.
The summary guidelines in Table 8-3 indicate the minimum privilege requirements for common classes of system users.
1The general purpose system manager often needs an authorized privilege set consisting of all privileges except BYPASS.
8.7.3 Limiting User Privileges
Granting privileges allows users those privileges until you remove them. To avoid such blanket permission, you may want to grant privileges on an as-needed basis. For example, certain users may need to run a program requiring one of the more powerful privileges. You can install the program with the necessary privilege by using the Install utility (INSTALL). Section 8.7.4 discusses installing privileged images in more detail.
An alternative to granting blanket privileges is to set up emergency or specialized privileged accounts. Users would log in to these privileged accounts only to perform specific functions. You have two options with this technique:
With both options, you can place special restrictions on the privileged account, such as long passwords, brief password lifetimes, restricted hours, and limited modes of operation (no dialup, network, remote, or batch logins). In addition, limited account durations would force frequent consideration of privilege requirements.
A user cannot execute an image that requires a privilege the user does not possess unless the image is installed as a known image with the privilege in question. (See the OpenVMS System Management Utilities Reference Manual for instructions on installing known images.) Execution of a known image with privileges grants those privileges to the user process executing the image for the duration of the image's execution. Thus, you should install images with amplified privileges (other than the normal Compaq-supplied configuration) only after ensuring that the privileges are required by the image's function and that the image operates safely. Also consider restricting access to the image to a selected set of users.
Images installed with privileges are activated with all amplified privileges enabled. For maximum safety, images designed to run with amplified privilege should use the $SETPRV system service to disable all amplified privileges immediately on activation, and enable them only when they are needed.
Following is an example of installing an image with privilege. The System Dump Analyzer utility (SDA) requires CMKRNL privilege to analyze the running system.
8.7.5 Restricting Command Output
Some DCL commands behave differently depending on the privileges that the user holds.
For example, unless a user holds the GROUP or WORLD privilege, the SHOW
PROCESS command limits the display of process information to the user's
process. A user with GROUP privilege can display other processes in the
user's UIC group; a user with WORLD privilege can display any process
on the system.
After designing user groups and identifiers, you need to address which protected objects your users need permission to access and which ones can be unrestricted. Become familiar with the default protection of new objects, shown in Chapter 5, and when necessary modify the defaults, as shown in the following sections.
The procedure for setting up object protection and ownership defaults
varies, depending on whether the object is a file or another class of
As Section 5.4.5 explains, there are four possible areas where you can specify protection defaults that would affect the user. In order of increasing influence, they are as follows:
Also consider the protection imposed on the volume through the DCL command SET VOLUME/PROTECTION. This protection code, if specified, prevents a user from accessing any part of the volume, regardless of the protection code on the directory or the file. If no volume protection is specified with the SET VOLUME command, the volume is accessible to all users.
The assignment of file ownership affects the outcome of any protection check. The operational effect of this combined protection structure is depicted in Figure 8-1.
Figure 8-1 Flowchart of File Creation
126.96.36.199 Adjusting Protection Defaults
You may want to make adjustments to control default behavior. The systemwide default protection code specified by the system parameter RMS_FILE PROT sets the user's default protection to the following:
Assume that the volume protection has been set by the operator to the following:
The file protection on the directory [PROJECT] has been set to the following:
If all the files created in the subdirectory [PROJECT.DIARY] demand more protection, you, or any user who has control access to the directory, could define a specific default protection code for this specific directory with an ACL consisting of a Default Protection ACE, as follows:
Once this ACE is placed on the directory file, files created or modified in the directory are subject to the default protection code. Because these protection codes are only defaults, a user who has control access to a file in the directory can include a specific protection code as a replacement for the default value on the file by using the following DCL commands:
Once the default protection code is replaced, the new code becomes the default and is propagated to subsequent versions of the file.
If you provide a special login command procedure for some of your users, you may want to supplement the systemwide default process protection specified by the system parameter RMS_FILEPROT for this group of users. Add the SET PROTECTION/DEFAULT command to the login command procedure to specify the default process protection, as follows:
Files created in users' directories receive this default protection
code unless explicitly overridden.
To allow for more flexible data management as well as more accurate accounting of disk space, you can set up a directory that is owned by a resource identifier and rely on ACLs to control access to the directory and to files created within it.
The ACL can limit file access to all project members holding the project identifier. To achieve this kind of access restriction, you add an Identifier ACE to define the group's access to files. A second Identifier ACE is added that duplicates the first but holds the Default attribute. It is the Default attribute that ensures the ACE is copied to all files created within the directory. Sometimes a third ACE is necessary---a Default Protection ACE, depending on the default protection code for the directory. A Default Protection ACE establishes the protection code for the directory's files. (As Section 4.3 explains, if an ACL denies access to a file, it is still possible to gain access through a protection code.)
In addition to limiting the group's access to files, an ACL can control
the type of access users have to files that they have created within
the common directory. Because the file is created in the resource
identifier's directory, the resource identifier owns the file. For
users to access files they have created, the operating system normally
gives control access to the file's creator plus the access specified in
the owner field of the protection code. However, you can modify this
behavior by adding a Creator ACE to the directory's ACL. A Creator ACE
defines the type of access users have to files they have created in the
A security administrator used the following command sequence to set up the project identifier PROJECTX and grant it to members of the project. Notice that the identifier is added to the rights database with the resource identifier, and it is also granted to users with the resource identifier. The project identifier needs to carry the Resource attribute so it can own disk space.