HP OpenVMS Guide to System Security: OpenVMS Version 8.4 > Chapter 8 Controlling Access to System Data and Resources
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 “Descriptions of Object Classes”Chapter 5, and when necessary modify the defaults, as shown in the following sections.
As “Profile Assignment”"Profile Assignment" on page 98 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 “Flowchart of File Creation”, “Flowchart of File Creation”, and “Flowchart of File Creation”.
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:
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:
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:
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 “How the System Determines if a User Can Access a Protected Object”"How the System Determines If a User Can Access a Protected Object" on page 74 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 project's directory.
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.
When a project- or department-specific identifier is the owner of a directory, the space used by files created in the directory can be charged to the appropriate department or project rather than to the individual who creates them. When users work on multiple projects, they can charge their disk space requirements to the related project rather than to their personal accounts.
In setting up a directory for a resource identifier, you first create the disk quota authorization for the project identifier. For example, the following command invokes the System Management utility (SYSMAN) and assigns the identifier PROJECTX 2000 blocks of disk quota with 200 blocks of overdraft:
After setting up the disk quota, you create the project directory. For example, the following DCL command creates the project directory [PROJECTX] and establishes the identifier PROJECTX as its owner:
Without a Creator ACE, project members each have complete access to files they have created in the directory. For example, Ross would receive the following access to files created in the project directories:
With the exception of files and pseudo-terminal (FT) devices, all classes of protected objects offer one or more template profiles that provide security elements for new objects. You can thus use a single mechanism to establish the default protection code, ACL, and ownership elements for objects. The operating system always stores these values so they are available from one system startup to the next. The SHOW SECURITY command displays the current default values for your particular site. See the “Descriptions of Object Classes”Chapter 5 for a listing of the operating system's default values.
The operating system generates the security profiles of new objects from data stored by security class objects. These objects are all logical constructs used to keep track of such class elements as the valid access types, the templates, and the types of auditing that have been enabled. As “Security Class Object” shows, every class of protected object has a member in the security class. All members have a security profile template, except for files, which have their own rules.
To display any class template, use the SHOW SECURITY/CLASS=SECURITY_CLASS command. The following command, for example, displays templates available for logical name tables. The logical name table object has the following three templates:
All objects in the security class are protected in the same manner as other objects. For this reason, any SHOW SECURITY display of a security class object begins with the security profile for the object itself. The following display shows a profile for the logical name table object in the security class. The object is owned by the system, and its protection code allows read access to any user category but allows write access only to system and owner categories.
The following command modifies the MAILBOX template for the device class. It changes the template values from a protection of S:RWPL,O:RWPL,G:RWPL,W:RWPL to a protection that disallows group and world access.
The operating system saves the default object protections specified in security templates, so rebooting the system automatically ensures that all objects created after the reboot are created with the new default protections.
The DCL command SHOW SECURITY displays all available templates with the site values. “Descriptions of Object Classes”Chapter 5 lists the default system values.