|
 HP OpenVMS Guide to System Security |
 Security for the User |
| Protecting Data |
|
|
| |
Definition of a Protected Object
The objects of the OpenVMS operating system that require protectionare all passive repositories that either contain or receive information.These objects are protected because once you have access to theobject, you have access to the information it holds. Some examplesof protected objects include:
Specifying an Object's Class lists the classesof objects that OpenVMS protects; refer to Descriptions of Object Classes for an in-depth description of each class.
Contents of an Object's Profile
The security elements of any object comprise its securityprofile. An object's security profile contains the followingtypes of information:
With the exception of files, a new object inherits its securityelements from a system-supplied template profile, which the sitesecurity administrator may modify. Files have a more complicatedinheritance mechanism, one that affords greater control over thesecurity elements of new objects. In all cases, you can assign securityelements during object creation rather than using the operatingsystem 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 greaterdetail. Refer to Descriptions of Object Classes fora description of individual object classes.
Owner
The first element of an object's security profile is the UICof 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 automaticallyassigns your UIC to the object and uses it in making access decisions.
There are some exceptions to the ownership rule. Files ownedby resource identifiers do not have a UIC. When a user creates afile in the directory of a resource identifier, the file may beowned by the resource identifier and not the user who created thefile (see Profile Assignment). Referto Descriptions of Object Classes for an explanationof the ownership rules for each object class.
The owner of any object except a file can reassign ownershipto another user with the SET SECURITY/OWNER command, as describedin Modifying a Security Profile. Changingthe owner of a file usually requires privilege (see Types of Access).
Protection Code
The second element of an object's security profile is theobject's protection code.
The system automatically assigns a protection code to eachnew object. The protection code associated with an object determinesthe type of access allowed to a user, based on the relationshipbetween the user UIC and the owner UIC. With the exception of filesand pseudo-terminal (FT) devices, the code a protected object receives isderived from a template profile for the class. (A file's protectioncode originates from another source, described in Files.)
Typically, you rely on the protection code to protect an objectif the object is to be accessed by: (a) only the owner, (b) allusers on the system, or (c) a specific UIC-based group of users.If you want to grant access to specific groups of users outsidethe UIC group but not to all users on the system, then you needto add an ACL (see Access Control List (ACL)).
Interpreting a Protection Code
A protection code defines the access rights for four categoriesof users: (a) the owner, (b) the users who share the same groupUIC 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 thenworld (W). It has the following syntax: [user category: access allowed (,user category: accessallowed,...)]
When the operating system processes a request to use a protectedobject, 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. Failinga match of UICs, the system progresses through the other user categories.The system tries to find a match of the group fields to determineif there is a common group membership. The system may also evaluatewhether the UIC group number indicates the user belongs to the systemcategory of users. The world category applies to all users.
For example, user Jones has a UIC of [14,1], and he triesto read a file that is owned by UIC [14,5]. Because Jones is inthe same group (14), the system might grant access to the file.The final decision depends on the access rights specified in theprotection code.
See Controlling Access with Protection Codes fora complete description of how to interpret and create protectioncodes.
AccessControl List (ACL)
The third (optional) element of an object's security profileis the object's access control list.
An access control list (ACL) is a collection of entries thatdefine the access rights a user or group of users has to a particularprotected 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 becreated 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, someusers may be unaware that their objects have ACLs and may neverchange ACLs themselves. (You can use the DCL command DIRECTORY/SECURITYor SHOW SECURITY to see if there are ACLs on your files.) Otherusers are actively involved in creating and maintaining their ownACLs.
Using ACLs is optional. Although ACLs can enhance the securityof objects in any installation through a more detailed definitionof who is allowed what kind of access, users have to spend timecreating and maintaining the ACLs.
You use the DCL commands SET SECURITY and SHOW SECURITY forcreating and displaying ACLs, althoughthe access control list editor (ACL editor) is an important utilityfor more extensive work.
Controlling Access with ACLs continuesthe discussion of ACLs and how to use them.
Displaying a Security Profile
To see the security profile of any protected object, use theDCL command SHOW SECURITY. For example, the following command requestssecurity information about the file 93_FORECAST.TXT:
The display indicates the file 93_FORECAST.TXT is owned byuser Greg. It also lists the file's protection code, which givesread, write, execute, and delete access to system users and theowner. The code grants read and execute access to group users andprovides no access to world users. (See Controlling Access with Protection Codes for further explanation.) There is no ACL on thefile as yet.$SHOW SECURITY 93_FORECAST.TXTWORK_DISK$:[GREG]93_FORECAST.TXT;1 object of class FILEOwner: [ACCOUNTING,GREG]Protection: (System: RWED, Owner: RWED, Group: RE, World)Access Control List:<empty>
Modifying a Security Profile
You can provide new values for the owner, protection code,or ACL of a protected object or even copy a profile from one objectto another by using the SET SECURITY command.
For example, the SHOW SECURITY display in Displaying a Security Profile shows the file 93_FORECAST.TXTis owned by user Greg. As owner, he can change the protection codefor that file. Originally, the code gave no access to users in theworld category. Now, Greg changes that to allow read and write accessto world users:
The SHOW SECURITY command verifies the new protection codefor the file:$SET SECURITY/PROTECTION=(W:RW) 93_FORECAST.TXT
Specifying an Object's Class shows how tomodify other elements in a profile. Controlling Access with ACLs and Controlling Access with Protection Codes discuss protection codes and ACLs extensively. Fora full description of the SET SECURITY and SHOW SECURITY commands,see the HP OpenVMS DCL Dictionary.$SHOW SECURITY 93_FORECAST.TXT93_FORECAST.TXT object of class FILEOwner: [GREG]Protection: (System: RWED, Owner: RWED, Group: RE, World: RW)Access Control List:<empty>
Specifying an Object's Class
Groups of objects that behave in a particular way and havea common set of attributes are divided into classes. Files, queues,and volumes are very common examples. As Classes of Protected Objects shows, the operating system supports 11 classesof protected objects.
When you modify the profile of an object, you need to specifythe class of the object; otherwise, the SET SECURITY command assumesthe object is a file.
For example, the following command sequence changes the profileof an object and uses the /CLASS qualifier to identify the objectLNM$GROUP as a logical name table:
The SET SECURITY command makes the Accounting group ownerof the logical name table. It changes the protection code to allowread, write, create, and delete access for the owner and for systemusers and to limit group and world users to read access. Finally,it creates an ACL to allow control access for user Chekov and to allowread and write access for user Wu.$SET SECURITY /CLASS=LOGICAL_NAME_TABLE-_$/OWNER=ACCOUNTING /PROTECTION=(S:RWCD, O:RWCD, G:R, W:R)-_$/ACL=((IDENTIFIER=CHEKOV,ACCESS=CONTROL),-_$(IDENTIFIER=WU,ACCESS=READ+WRITE)) LNM$GROUP
The SHOW SECURITY command displays the results of the changes:
$SHOW SECURITY LNM$GROUP /CLASS=LOGICAL_NAME_TABLELNM$GROUP object of class LOGICAL_NAME_TABLEOwner: [ACCOUNTING]Protection: (System: RWCD, Owner: RWCD, Group: R, World: R)Access Control List:(IDENTIFIER=[USER,CHEKOV],ACCESS=CONTROL)(IDENTIFIER=[USER,WU],ACCESS=READ+WRITE)
Refer to Descriptions of Object Classes fora detailed description of each class.
Access Required to Modify a Profile
To modify a security profile, you need control access to theobject. An ACL grants control access explicitly, whereas a protectioncode grants it implicitly to anyone who belongs to the owner orsystem category. (Refer to Using Control Access to Modify an Object Profile for a full description of how you can acquire control access.)
|
|
