HP OpenVMS Guide to System Security: OpenVMS Version 8.4 > Chapter 4 Protecting Data
“Access Control List (ACL)” introduced access control lists (ACLs) as one element of an object's security profile. This section explores this protection mechanism in depth and provides examples of how to use ACLs effectively to protect objects.
Many users do not need to bother with ACLs because the protection codes that the operating system automatically assigns to objects are often sufficient. But there are times when you need to allow specific users access to your files, for example, when you are working on a common project. Because ACLs are an effective mechanism for protecting critical system files, devices, volumes, and other protected objects, system managers and security administrators use ACLs more often than general users.
Each entry in an access control list (ACL) is called an access control entry (ACE). An ACL can have many entries, each of which defines some attribute of an object. There are many kinds of ACEs, which you can read about in the HP OpenVMS System Management Utilities Reference Manual. Of interest here is the Identifier ACE, which controls access to objects.
An Identifier ACE includes one or more rights identifiers and a list of the types of access the users holding the identifier have permission to exercise. When the system evaluates a user's rights to an object, it scans the object's ACL until it finds an Identifier ACE that matches one or more rights identifiers held by the accessing user; it grants or denies access based on that entry.
The types of access that are granted (or denied) by an ACE depend on the object you are protecting. For example, you can read, write to, execute, and delete a file; whereas you can perform physical and logical operations on a device as well as reading and writing to it. Thus, a file supports read, write, execute, and delete access, and a device supports read, write, physical, and logical access. See “Descriptions of Object Classes” for information on the types of access other object classes support.
Because identifiers define the rights of individual users or groups of users (see “Types of Identifiers”), you use them in an Identifier ACE to define the access granted (or denied) to those who hold them. A UIC identifier easily identifies an individual user or a group of users on the system. When a group of users from diverse functional groups (and therefore, diverse UIC groups) all need access to a protected object, a security administrator creates a general identifier and grants the identifier to all the users who need access.
For example, the following command grants user Pat, who is identified by the UIC identifier [PAT], read, write, and execute access to a file located in the ROBERTS directory on DISK1. The ACL denies Pat delete and control access because it omits them from the access statement.
A security administrator uses the Authorize utility to create a general identifier and grant it to all users who need to use it. Assume, for example, that a security administrator has created and assigned the identifier PAYROLL to employees who need access to a payroll file. For the holders of the identifier to actually access the file, the administrator has to add an Identifier ACE to the file. For example, the following command creates an ACL for the PAYROLL file that gives holders of the PAYROLL identifier read access to the file:
The order of ACEs in an ACL is important because of the operating system's processing rules. See “Ordering ACEs Within a List” for information on ordering ACEs.
Besides providing access to objects, an Identifier ACE is often used to deny certain users access to an object. Some sites might use an ACL to restrict users who log in from a modem or over the network. Other sites might place a restricting ACE on expensive equipment or volumes containing sensitive files.
To deny all access to holders of a particular identifier, use the NONE keyword as the access type name. For example, the following command denies holders of the environmental identifier DIALUP any access to the files in the PROJECT-ACCOUNTS directory:
Denying access with the NONE keyword requires some additional planning. You must position the ACE correctly in the ACL, as “Ordering ACEs Within a List” describes, because the operating system grants or denies access based on the first matching ACE. (Alternatively, you can eliminate any access allowed through the group or world category of the protection code [see “How the System Determines if a User Can Access a Protected Object” and “Enhancing Protection for Sensitive Objects”, in particular].) Security administrators may also want to rescind privileges that can override the matching ACE.
Although a security administrator may want to provide access to a common file, such as the payroll file described in “Granting Access to Particular Users”, 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 “Preventing Users from Accessing an Object”. Still, the ACL on the printer TTA8 might not work exactly as intended until the security administrator modifies the printer's protection code. See “Enhancing Protection for Sensitive Objects” 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 “Types of Identifiers”.) 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:
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 “How the System Determines if a User Can Access a Protected Object” for a description of the evaluation process.
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 identifier, you can add the following ACE to the file MALCOLM.DIR:
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 “Restoring a File's Default Security Profile”, 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:
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 HP 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 ignore it.
“Granting Access to Particular Users” through “Limiting Access to an Environment” 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:
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, use the following command:
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:
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.
If you want to restore the default ACL to a file, you can use the /DEFAULT qualifier to the SET SECURITY command. This qualifier regenerates the full security profile for a file. See “Restoring a File's Default Security Profile” for a description.
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:
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.)
See the ACL editor documentation in the HP OpenVMS System Management Utilities Reference Manual for details on the different attributes an ACE can have, and also see the HP OpenVMS Programming Concepts Manual for a description of all ACE types.