Controlling Access with Protection Codes

If both a Table of Contents and Search form are not displayed in separate frames along with this one, you may wish to redisplay this book in a frameset, beginning with the first page.

HP OpenVMS Guide to System Security

Security for the User

Protecting Data

Controlling Access with ACLs

Understanding Privileges and Control Access

Controlling Accesswith Protection Codes

A protection code controls the type of access allowed (ordenied) to a particular user or group of users. Access types identifythe capabilities required to perform an operation on a protectedobject. The operating system can have multiple access requirementsto complete an operation (see Enabling Auditing for a Class of Objects). A user can gain access to an object as soonas the operating system finds a category within the protection codefor which the user qualifies that allows the access requested (providedan ACL does not deny access).

Format of a Protection Code

A protection code has the following format: [user category: list of access allowed (, user category:list of access allowed,...)]

user category

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:

System:Members of this category can include any of the following:

Users with low group numbers, usuallyfrom 1 to 10 (octal). These group numbers are generally for systemmanagers, security administrators, and system programmers. (Theexact range of system group numbers is determined by the securityadministrator in the setting of the system parameter MAXSYSGROUP.It can range as high as 37776 (octal).)

Users with the SYSPRV privilege.

Users with the GRPPRV privilege whose UIC groupmatches the UIC group of the object's owner.

In access requests to files on a disk volume, userswhose UIC matches the UIC of the volume's owner.

Owner: The userwith the same UIC as the user who currently owns the object. Ingeneral, the creator of an object is entitled to owner access unlessexplicit action is taken to secure the object from its creator.

Group: All userswho are in the same UIC group as the object's owner.

World: All users,including those in the first three categories.

When specifying more than one user category, separate thecategories with commas, and enclose the entire code in parentheses.You can specify user categories and access types in any order (althoughthe system always displays them in the order system, owner, group,world).

To deny all access to a user category, specify the user categorywithout any access types. Omit the colon after the user categorywhen you are denying access to a category of users.

Omitting a category entirely means access to the categoryis unspecified. The current access allowed that category of userremains unchanged. If the protection code applies to an object beingcreated (for example, with a COPY/PROTECTION command), the omittedcategory is assigned the default value.

access-list

Access types are object-dependent and are described in Descriptions of Object Classes. For files, the accesstypes include read (R), write (W), execute (E), and delete (D).The access type is assigned to each user category and is separatedfrom its user category by a colon (:), for example, SET SECURITY/PROTECTION=(S:RWE,O:RWE,G:RE,W).

Types of Access in a Protection Code

Each category of user can be allowed or denied different typesof access. The exact type is dependent on the object being protected.Each object class defines access types appropriate for its classand representative of the ways in which users operate on the data.For example, while the file object supports read, write, execute, anddelete access, devices (such as terminals, printers, and disks)support read, write, physical I/O, and logical I/O access. See Descriptions of Object Classes for a listing of theaccess types each object class supports.

All protected objects also support control access,which allows a user to examine and modify the security elements(ACL, protection code, UIC) and possibly other attributes of theobject. Control access is explicitly stated in an ACL but neverappears in the UIC-based protection code. All users who qualifyfor the system or owner categories of a protection code have controlaccess. Users in the group and world categories never receive controlaccess through a protection code, but they could receive accessthrough an ACL. See Using Control Access to Modify an Object Profile formore information.

The capabilities conveyed by the access types read, write,execute, delete, and control vary depending on the situation wherethey apply. For example, execute access permits different operationsdepending on whether it is granted for file access or directoryaccess. Descriptions of Object Classes explainsthe capabilities that each access type allows for each type of protectedobject.

Processing a Protection Code

When the system evaluates a protection code, it looks firstat the owner field, then at the world field, the group field, andfinally the system field. As soon as a user qualifies as a memberof the category and that category grants the necessary access, theoperating system stops processing the code (see Flowchart of Access Request Evaluation).

The following protection code specifies that users in thesystem and owner categories have read (R), write (W), execute (E),and delete (D) access, while users in the group and world categorieshave only read and execute access:

$ SET SECURITY/PROTECTION=(SYSTEM:RWED, OWNER:RWED, GROUP:RE, WORLD:RE)-_$ TAXES_91.DAT

When you want to deny access to a user category, you mustdeny access to all the outermost categories. As Format of a Protection Code shows, any user process or applicationqualifies for world access. The group category is more restrictiveyet not as restrictive as the owner and system categories.

The following protection code, for example, appears to denydelete access to the owner category:

$ SHOW SECURITY TAXES_91.DAT

WORK_DISK$:[GREG]TAXES_91.DAT;1 object of class FILE      Owner: [FINANCE,GREG]     Protection: (System: RWED, Owner: RW, Group:RW, World:RWED)     Access Control List: ...

However, the owner of the file can still delete the file.Although delete access is not allowed through the owner category,the system continues to check the remaining categories for permissionto grant access. Because the owner also fits in the world category(which applies to all users) and the world category is permitteddelete access, the system grants delete access to the owner.

Changing a Protection Code

You can change the UIC-based protection on an existing objectwith the SET SECURITY command. The following command modifies theprotection code of the file SURVEY.DIR so that anyone in the systemand owner categories has read, write, execute, and delete access;whereas members of the group and world categories have read andexecute access:

$ SET SECURITY/PROTECTION=(SYSTEM:RWED,OWNER:RWED, -_$ GROUP:RE,WORLD:RE)  SURVEY.DIR

Whenever you omit a category from a protection code, the currentaccess remains unchanged. For example, consider the protection codefor the file RECORDS_91.DAT:

$ SHOW SECURITY RECORDS_91.DAT

WORK_DISK$:[GREG]RECORDS_91.DAT object of class FILE     Owner: [VMS,GREG]     Protection: (System: RWED, Owner: RWED, Group: RWED, World: RE)

As it stands, the file RECORDS_91 allows read, write, execute,and delete access to users in the system, owner, and group categories;it allows read and execute access to users in the world category.The following DCL command resets the protection code for RECORDS_91.DATto deny write and delete access to the group category and to denyall access to the world category:

$ SET SECURITY/PROTECTION=(G:RE,W) RECORDS_91.DAT

The next command confirms the modified protection code. Itshows that the system and owner categories of users continue tohold read, write, execute, and delete access, while group usershave only read and execute access and world users have no access.

$ SHOW SECURITY RECORDS_91.DAT

WORK_DISK$:[GREG]RECORDS_91.DAT object of class FILE     Owner: [VMS,GREG]     Protection: (System: RWED, Owner: RWED, Group: RE, World:)

Enhancing Protection for Sensitive Objects

Limiting Access to a Device describeshow to place an ACL on an important printer so that only one usercan have access to it. Before the ACL can be effective, however,the security administrator has to eliminate all access providedthrough the printer's protection code by using the following command:

$ SET SECURITY/PROTECTION=(S,O,G,W)/CLASS=DEVICE TTA8:

The security administrator then uses an ACL to assign accessexplicitly.

For example, to limit access to a queue, you can remove submitaccess for the world category. Then you can set up an ACL that specifieswhich users (from the world category) are permitted to submit jobsto the queue. The following command stipulates that only holdersof the identifier PROJECTX can submit jobs to the LN03$PRINT queue:

$ SET SECURITY/CLASS=QUEUE/PROTECTION=(W) -_$ /ACL=(IDENTIFIER=PROJECTX,ACCESS=SUBMIT) -_$ LN03$PRINT

Important files frequently need special protection. You canprevent users from seeing the contents of a directory by denyingthem read access. To further protect the files, you can add a DefaultProtection ACE to the directory file, as Providing a Default Protection Code for a Directory Structure describes.

Providing a Default Protection Code for aDirectory Structure

To specify default protection for new files in a particulardirectory, place a Default Protection ACE in the ACL of the directoryfile. The Default Protection ACE affects files that are subsequentlycreated in the directory and in any subdirectories under that directoryunless protection is specified for one of those files individually. ThisACE type has the following format: (DEFAULT_PROTECTION[,options],protection-code)

For example, the following ACE specifies that users in thesystem and owner categories have read, write, execute, and deleteaccess to any files subsequently created in the directory and thatgroup and world users have no access:

$ SET SECURITY/ACL=(DEFAULT_PROTECTION,S:RWED,O:RWED,G,W) ARCHIVE.DIR

Be aware that the default protection is associated only withnewly created files -- not existing files in the current directoryand its subdirectories. If you add a Default Protection ACE to adirectory file and want the same protection applied to existingfiles, you must explicitly change the protection with the following command:

$ SET DEFAULT [ARCHIVE] $ SET SECURITY/PROTECTION=(S:RWED,O:RWED,G,W) [...]*.*;*

Restoring a File's Default Security Profile

The /DEFAULT qualifier of the SET SECURITY command regeneratesthe security profile of a file. The /DEFAULT qualifier resets theprotection code, the ACL, and the owner elements of the file tothe defaults specified by the file's parent directory (that is,to the directory's default ACL, default protection ACE, if any, andowner UIC).

The profile is recreated according to the following rules:

The protection code is propagatedfrom the Default Protection ACE on the directory (if one exists),or else it is propagated from the process default.

The ACL is propagated from the parent directoryfor those ACEs that have the Default attribute.

The owner is set to the owner of the parent directory.(Be aware that modifying a file's owner generally requires privilege;see Types of Access.)

With subdirectory files, SET SECURITY assigns the owner, protection,and ACL elements of the parent directory.

SET SECURITY does not copy any ACE on the source object ifit holds the Nopropagate attribute, nor does it change any ACE onthe target object if it holds the Protected attribute. To applynew elements to all versions of the file, specify ;* in the objectname.

Refer to Profile Assignment formore information on propagation rules.

Controlling Access with ACLs

Understanding Privileges and Control Access