HP OpenVMS Systems Documentation
OpenVMS Guide to System Security
4.4.4 Limiting Access to a Device
Although a security administrator may want to provide access to a common file, such as the payroll file described in Section 4.4.2, the administrator would want to ensure that only a limited number of people could use the letter-quality printer designated for printing checks. Otherwise, any holder of the payroll identifier could access the check forms that are always loaded in the printer TTA8.
Because the check printer in the current example is never used for logins and no queues are directed to it, the security administrator can add an ACL to the printer to ensure that only one user, McGrey, is allowed read and write access. At the same time, the administrator must block printer access for all other identifier holders. The following command sequence creates such an ACL:
While McGrey acquires read and write access, all other users are denied
access with the NONE keyword, explained in Section 4.4.3. Still, the
ACL on the printer TTA8 might not work exactly as intended until the
security administrator modifies the printer's protection code. See
Section 4.5.5 for details.
With an Identifier ACE, it is possible to provide conditional access by combining certain kinds of identifiers. A common situation is to use a UIC identifier with one of the environmental identifiers like batch or interactive. (For a complete list of environmental identifiers, see Section 188.8.131.52.) Thus, a user can access a protected object only when running in batch mode or interactively but never over a dialup line. For example, the next command grants user Fred both submit and manage access to a print queue, but only while he is running a batch job:
4.4.6 Ordering ACEs Within a List
An ACL can contain one entry or many entries. With multiple ACEs, the order of the entries is critical because the system determines access based on the first matching ACE. The operating system searches an ACL sequentially and grants a user the access specified in the first matching ACE, thus ignoring all subsequent entries. See Section 4.3 for a description of the evaluation process.
When writing ACLs, keep the following principles in mind:
The following ACL on the directory file PROJECT-ACCOUNTS.DIR demonstrates how to order entries in an ACL. It places ACEs giving access to critical users (Jones and Fred) at the top of the list and places general ACEs after them. The ACE denying access goes at the end.
The ACL on the project accounts directory allows read, write, and execute access to Jones all the time and to Fred while he is running a batch job. It gives read access to users holding the PAYROLL identifier. All users who are logging in from a modem are denied access unless they gain access through an earlier ACE. For example, Jones, Fred, or holders of the PAYROLL identifier might be dialing in, but, because their ACE precedes the DIALUP ACE, they would be granted access.
In this ACL, any users holding the SECURITY identifier obtain maximum
access rights through the first ACE, and users holding the PERSONNEL
identifier have the next greatest access. User Jones is prohibited from
any access to the file unless Jones also happens to hold one of the
general identifiers. (This might be an oversight on the part of the
creator of the ACL.) If you want to be absolutely certain that user
Jones cannot gain access to the file, move the entry at the bottom of
the ACL to the top.
You can create a plan for controlling access to files within a directory or a directory structure, develop an appropriate ACL for the files, and then direct the operating system to automatically assign this ACL to new files. To do this, create an Identifier ACE with the Default attribute, and then add the ACE to the directory file cataloging the files you want to affect. Use the OPTIONS keyword to include the Default attribute.
For example, if you want all new files in the directory [MALCOLM] to have an ACL entry that permits read and write access to users with the PERSONNEL
As a result of this ACE, any file created in the [MALCOLM] directory has the following ACL:
Notice that the Default attribute does not appear within a new file's ACL but only in the ACL of directory files. However, any subdirectory created in the MALCOLM directory automatically has the entry (IDENTIFIER=PERSONNEL,OPTIONS=DEFAULT,ACCESS=READ+WRITE) as part of its ACL. In this way, the ACE is propagated throughout the entire directory tree.
The ACE is not applied retroactively to existing versions of files in MALCOLM.DIR. To attach an ACE to existing files, you can use the /DEFAULT qualifier, described in Section 4.5.7, or use the following command:
Any ACE with a Default attribute controls only the propagation of the ACE; it has no effect on access control. To control access to the directory as well as all its files, you have to insert two ACEs in the directory's ACL, as follows:
4.4.8 Displaying ACLs
The DCL command SHOW SECURITY displays an object's ACL. When working with objects other than files, you must supply a class name as well as the object name. For example, the following display shows the security attributes of a device called PPA0. It is owned by the operating system, and its protection code gives full access (read, write, physical, and logical) to users in the system and owner categories but no access to group and world users; its ACL gives control access to user Svensen.
There are many other ways of displaying ACLs. The access control list editor (ACL editor) is a useful tool for extensive work with ACLs; see the ACL editor documentation in the OpenVMS System Management Utilities Reference Manual. But any of the following DCL commands display ACLs:
Applications sometimes add a Hidden attribute to an ACE to indicate that the ACE should be changed only by the application that adds the ACE. Unless users have the SECURITY privilege, they cannot display a hidden ACE by using DCL commands. The ACL editor does display ACEs holding the Hidden attribute but only to show its relative position within the ACL; however, unauthorized users cannot edit the ACE.
Sometimes you see other kinds of ACEs, unrelated to access control, in
an ACL. For example, if the security administrator places a
security-auditing ACE on the LN03$PRINT queue, you will see an ACE at
the top of the list that has the format
(AUDIT=SECURITY,ACCESS=access-types). Such an ACE is part of
the security-auditing system and has no effect on access, so you can
Section 4.4.2 through Section 4.4.5 discuss how to add entries to an empty ACL with the DCL command SET SECURITY. To modify ACLs extensively, use the ACL editor; however, in many cases the SET SECURITY command is more appropriate. This section and those that follow describe how to use SET SECURITY to change an ACL.
To add more entries to an ACL, you can use the /ACL qualifier with the SET SECURITY command and specify the new ACEs. For example, to give the writers access to the print queue LN03$PRINT, use the following command:
By default, the system places the new ACE at the top of the ACL, as you see in the following SHOW SECURITY display:
Because the default behavior for SET SECURITY is to place a new ACE at the top of an ACL, you need to use the /AFTER qualifier if you want to put the ACE in another position. For example, to position the TRADERS ACE in the queue's ACL after the WRITERS ACE:
The resulting display confirms the effectiveness of the /AFTER qualifier. The new ACE is put second in the list.
4.4.10 Deleting an ACL
The /DELETE qualifier on the SET SECURITY command erases an ACL. Depending on how the qualifier is used, you can delete all or part of an ACL. For example, the following command deletes a disk's ACL:
An ACE can be protected against inadvertent deletion if it holds the
Protected attribute. To eliminate a protected ACE, you
need to delete it explicitly or use the /DELETE=ALL qualifier on the
SET SECURITY/ACL command.
You can eliminate a subset of an ACL by listing the unwanted ACEs with the /ACL qualifier and including the /DELETE qualifier. For example, the following command deletes the ACEs giving holders of the TRADERS identifier and the NETWORK identifier write access to volume DBA0:
4.4.12 Replacing Part of an ACL
To replace one contiguous set of ACEs within an ACL with another set, specify the new ACEs with the /REPLACE qualifier and the ACEs to be deleted with the /ACL qualifier, as follows:
The TRADERS ACE specified by /ACL is deleted. Following the deletion, the ACEs specified by the /REPLACE qualifier (RESEARCH, STATE_DEPARTMENT, ENERGY_DEPARTMENT) are inserted at the location of the old ACE.
You can copy the security profile of one object to another by using the /LIKE qualifier to the SET SECURITY command. For example, you can save a complicated ACL on a nonpermanent object like a logical name table by copying it to a permanent object such as a file. Some administrators create a file to serve as a template in copy operations. This way, they can easily transfer an ACL from one object to another. For example, the following command copies the ACL from file ACL_TEMPLATE.TXT to the logical name table LNM$GROUP:
If you add the /COPY_ATTRIBUTE qualifier to the /LIKE qualifier, then you can copy one or two elements rather than the complete profile. Notice the ACL on the following directory, KITE_FLYING:
The following command copies the ACL from directory KITE_FLYING to the directory KITE_DESIGNS:
The SET SECURITY/LIKE command does not always duplicate the entire ACL of the source object. For example, the command does not copy any ACEs from the source ACL that have the Nopropagate attribute. The command also does not overwrite protected ACEs. It preserves protected ACEs on the target object and adds them to the ACL being copied. (For example, applications often use a special type of protected ACE to explain how to display file data correctly, and these ACEs have to be preserved.)
Refer to the ACL editor documentation in the OpenVMS System Management Utilities Reference Manual for details
on the different attributes an ACE can have, and refer to the
OpenVMS Programming Concepts Manual for a description of all ACE types.
A protection code controls the type of access allowed (or denied) to a
particular user or group of users. Access types
identify the capabilities required to perform an operation on a
protected object. The operating system can have multiple access
requirements to complete an operation (see Section 4.7.2). A user can
gain access to an object as soon as the operating system finds a
category within the protection code for which the user qualifies that
allows the access requested (provided an ACL does not deny access).
A protection code has the following format:
User categories include system (S), owner (O), group (G), and world (W). Each category can be abbreviated to its first character. Categories have the following definitions:
When specifying more than one user category, separate the categories with commas, and enclose the entire code in parentheses. You can specify user categories and access types in any order (although the system always displays them in the order system, owner, group, world).
To deny all access to a user category, specify the user category without any access types. Omit the colon after the user category when you are denying access to a category of users.
Omitting a category entirely means access to the category is unspecified. The current access allowed that category of user remains unchanged. If the protection code applies to an object being created (for example, with a COPY/PROTECTION command), the omitted category is assigned the default value.
Access types are object-dependent and are described in Chapter 5. For files, the access types include read (R), write (W), execute (E), and delete (D). The access type is assigned to each user category and is separated from its user category by a colon (:), for example, SET SECURITY/PROTECTION=(S:RWE,O:RWE,G:RE,W).