Security Profile of Objects
» Table of Contents |  | | » Glossary | | | » Index | | |
| | |
| ||
| ||
The objects of the OpenVMS operating system that require protection are all passive repositories that either contain or receive information. These objects are protected because once you have access to the object, you have access to the information it holds. Some examples of protected objects include:
A file in memory or on a storage device
A hardware device or a virtual device
A data structure, such as a common event flag cluster or a logical name table
“Specifying an Object's Class” lists the classes of objects that OpenVMS protects; refer to Chapter 5 “Descriptions of Object Classes” for an in-depth description of each class.
The security elements of any object comprise its security profile. An object's security profile contains the following types of information:
The owner of the object. The system uses this element in interpreting the protection code.
The protection code defining access to objects based on the categories of system, owner, group, and world. This protection code controls broad categories of users.
The access control list (ACL) controlling access to objects by individual users or groups of users.
With the exception of files, a new object inherits its security elements from a system-supplied template profile, which the site security administrator may modify. Files have a more complicated inheritance mechanism, one that affords greater control over the security elements of new objects. In all cases, you can assign security elements during object creation rather than using the operating system defaults.
This section gives an overview of protection codes and ACLs. “Controlling Access with ACLs” and “Controlling Access with Protection Codes” explore these protection mechanisms in greater detail. Refer to Chapter 5 “Descriptions of Object Classes” for a description of individual object classes.
The first element of an object's security profile is the UIC of its owner.
In most cases, if you create an object, you are its owner. As the owner, you can modify its security profile. The system automatically assigns your UIC to the object and uses it in making access decisions.
There are some exceptions to the ownership rule. Files owned by resource identifiers do not have a UIC. When a user creates a file in the directory of a resource identifier, the file may be owned by the resource identifier and not the user who created the file (see “Profile Assignment”). Refer to Chapter 5 “Descriptions of Object Classes” for an explanation of the ownership rules for each object class.
The owner of any object except a file can reassign ownership to another user with the SET SECURITY/OWNER command, as described in “Modifying a Security Profile”. Changing the owner of a file usually requires privilege (see “Types of Access”).
The second element of an object's security profile is the object's protection code.
The system automatically assigns a protection code to each new object. The protection code associated with an object determines the type of access allowed to a user, based on the relationship between the user UIC and the owner UIC. With the exception of files and pseudo-terminal (FT) devices, the code a protected object receives is derived from a template profile for the class. (A file's protection code originates from another source, described in “Files”.)
Typically, you rely on the protection code to protect an object if the object is to be accessed by: (a) only the owner, (b) all users on the system, or (c) a specific UIC-based group of users. If you want to grant access to specific groups of users outside the UIC group but not to all users on the system, then you need to add an ACL (see “Access Control List (ACL)”).
Interpreting a Protection Code
A protection code defines the access rights for four categories of users: (a) the owner, (b) the users who share the same group UIC as the owner (the group category), (c) all users on the system (the world category), and (d) those with system privileges or rights (the system category). A code lists access rights in a fixed order: the system category (S), then owner (O), then group (G), and then world (W). It has the following syntax:
[user category: access allowed (,user category: access allowed,...)]
When the operating system processes a request to use a protected object, it compares the user's UIC to the UIC of the object's owner. If the user's UIC is the same as the UIC of the object's owner, the user is granted the access of the owner protection field. Failing a match of UICs, the system progresses through the other user categories. The system tries to find a match of the group fields to determine if there is a common group membership. The system may also evaluate whether the UIC group number indicates the user belongs to the system category of users. The world category applies to all users.
For example, user Jones has a UIC of [14,1], and he tries to read a file that is owned by UIC [14,5]. Because Jones is in the same group (14), the system might grant access to the file. The final decision depends on the access rights specified in the protection code.
See “Controlling Access with Protection Codes” for a complete description of how to interpret and create protection codes.
The third (optional) element of an object's security profile is the object's access control list.
An access control list (ACL) is a collection of entries that define the access rights a user or group of users has to a particular protected object, such as a file, directory, or device.
ACLs may be created by default when an object is created, they may be created by the security administrator, or they may be created by users for objects to which they have control access (see “Using Control Access to Modify an Object Profile”).
Because security administrators can set up default ACLs, some users may be unaware that their objects have ACLs and may never change ACLs themselves. (You can use the DCL command DIRECTORY/SECURITY or SHOW SECURITY to see if there are ACLs on your files.) Other users are actively involved in creating and maintaining their own ACLs.
Using ACLs is optional. Although ACLs can enhance the security of objects in any installation through a more detailed definition of who is allowed what kind of access, users have to spend time creating and maintaining the ACLs.
You use the DCL commands SET SECURITY and SHOW SECURITY for creating and displaying ACLs, although the access control list editor (ACL editor) is an important utility for more extensive work.
“Controlling Access with ACLs” continues the discussion of ACLs and how to use them.
To see the security profile of any protected object, use the DCL command SHOW SECURITY. For example, the following command requests security information about the file 93_FORECAST.TXT:
|
|
|
The display indicates the file 93_FORECAST.TXT is owned by user Greg. It also lists the file's protection code, which gives read, write, execute, and delete access to system users and the owner. The code grants read and execute access to group users and provides no access to world users. (See “Controlling Access with Protection Codes” for further explanation.) There is no ACL on the file as yet.
You can provide new values for the owner, protection code, or ACL of a protected object or even copy a profile from one object to another by using the SET SECURITY command.
For example, the SHOW SECURITY display in “Displaying a Security Profile” shows the file 93_FORECAST.TXT is owned by user Greg. As owner, he can change the protection code for that file. Originally, the code gave no access to users in the world category. Now, Greg changes that to allow read and write access to world users:
|
|
|
The SHOW SECURITY command verifies the new protection code for the file:
|
|
|
“Specifying an Object's Class” shows how to modify other elements in a profile. “Controlling Access with ACLs” and “Controlling Access with Protection Codes” discuss protection codes and ACLs extensively. For a full description of the SET SECURITY and SHOW SECURITY commands, see the HP OpenVMS DCL Dictionary.
Groups of objects that behave in a particular way and have a common set of attributes are divided into classes. Files, queues, and volumes are very common examples. As Table 4-2 “Classes of Protected Objects” shows, the operating system supports 11 classes of protected objects.
When you modify the profile of an object, you need to specify the class of the object; otherwise, the SET SECURITY command assumes the object is a file.
For example, the following command sequence changes the profile of an object and uses the /CLASS qualifier to identify the object LNM$GROUP as a logical name table:
|
|
|
The SET SECURITY command makes the Accounting group owner of the logical name table. It changes the protection code to allow read, write, create, and delete access for the owner and for system users and to limit group and world users to read access. Finally, it creates an ACL to allow control access for user Chekov and to allow read and write access for user Wu.
The SHOW SECURITY command displays the results of the changes:
|
|
|
Table 4-2 Classes of Protected Objects
Refer to Chapter 5 “Descriptions of Object Classes” for a detailed description of each class.
To modify a security profile, you need control access to the object. An ACL grants control access explicitly, whereas a protection code grants it implicitly to anyone who belongs to the owner or system category. (Refer to “Using Control Access to Modify an Object Profile” for a full description of how you can acquire control access.)