Document revision date: 19 July 1999

Each category of user can be allowed or denied different types of access. The exact type is dependent on the object being protected. Each object class defines access types appropriate for its class and representative of the ways in which users operate on the data. For example, while the file object supports read, write, execute, and delete access, devices (such as terminals, printers, and disks) support read, write, physical I/O, and logical I/O access. See Chapter 5 for a listing of the access 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 the object. Control access is explicitly stated in an ACL but never appears in the UIC-based protection code. All users who qualify for the system or owner categories of a protection code have control access. Users in the group and world categories never receive control access through a protection code, but they could receive access through an ACL. See Section 4.6.2 for more information.

The capabilities conveyed by the access types read, write, execute, delete, and control vary depending on the situation where they apply. For example, execute access permits different operations depending on whether it is granted for file access or directory access. Chapter 5 explains the capabilities that each access type allows for each type of protected object.

4.5.3 Processing a Protection Code

When the system evaluates a protection code, it looks first at the owner field, then at the world field, the group field, and finally the system field. As soon as a user qualifies as a member of the category and that category grants the necessary access, the operating system stops processing the code (see Figure 4-3).

The following protection code specifies that users in the system and owner categories have read (R), write (W), execute (E), and delete (D) access, while users in the group and world categories have 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 must deny access to all the outermost categories. As Section 4.5.1 shows, any user process or application qualifies for world access. The group category is more restrictive yet not as restrictive as the owner and system categories.

The following protection code, for example, appears to deny delete 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 permission to grant access. Because the owner also fits in the world category (which applies to all users) and the world category is permitted delete access, the system grants delete access to the owner.

4.5.4 Changing a Protection Code

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

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

Whenever you omit a category from a protection code, the current access remains unchanged. For example, consider the protection code for 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.DAT to deny write and delete access to the group category and to deny all access to the world category:

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

The next command confirms the modified protection code. It shows that the system and owner categories of users continue to hold read, write, execute, and delete access, while group users have 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:)

4.5.5 Enhancing Protection for Sensitive Objects

Section 4.4.4 describes how to place an ACL on an important printer so that only one user can have access to it. Before the ACL can be effective, however, the security administrator has to eliminate all access provided through 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 access explicitly.

For example, to limit access to a queue, you can remove submit access for the world category. Then you can set up an ACL that specifies which users (from the world category) are permitted to submit jobs to the queue. The following command stipulates that only holders of 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 can prevent users from seeing the contents of a directory by denying them read access. To further protect the files, you can add a Default Protection ACE to the directory file, as Section 4.5.6 describes.

4.5.6 Providing a Default Protection Code for a Directory Structure

To specify default protection for new files in a particular directory, place a Default Protection ACE in the ACL of the directory file. The Default Protection ACE affects files that are subsequently created in the directory and in any subdirectories under that directory unless protection is specified for one of those files individually. This ACE type has the following format:

(DEFAULT_PROTECTION[,options],protection-code)

For example, the following ACE specifies that users in the system and owner categories have read, write, execute, and delete access to any files subsequently created in the directory and that group 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 with newly created files---not existing files in the current directory and its subdirectories. If you add a Default Protection ACE to a directory file and want the same protection applied to existing files, you must explicitly change the protection with the following command:

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

4.5.7 Restoring a File's Default Security Profile

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

The profile is recreated according to the following rules:

• The protection code is propagated from 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 directory for 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 Section 5.4.2.)

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 if it holds the Nopropagate attribute, nor does it change any ACE on the target object if it holds the Protected attribute. To apply new elements to all versions of the file, specify ;* in the object name.

Refer to Section 5.4.5 for more information on propagation rules.

4.6 Understanding Privileges and Control Access

Although an object can be carefully protected by an ACL and a protection code, a user can still gain access through the use of privilege or control access.

4.6.1 How Privileges Affect Protection Mechanisms

Security administrators can assign privileges to users when they create or modify user accounts. The system privileges READALL and BYPASS affect user access, regardless of the access dictated by an ACL for the object or by other elements in its security profile. The privileges SYSPRV and GRPPRV are controlled through the system category of the protection code. The privileges have the following meanings:

BYPASS	A user with BYPASS privilege receives all types of access to the object, regardless of its protection.
GRPPRV	A user with GRPPRV privilege whose UIC group matches the group of the owner of the object receives the same access accorded to users in the system category. Thus, the user with GRPPRV privilege is able to manage any of the group's objects.
READALL	A user with READALL privilege receives read access to the object, even if that access is denied by the ACL and the protection code. In addition, the user can receive any other access granted through the protection code.
SYSPRV	A user with SYSPRV privilege receives the access accorded to users in the system category.

When you define ACLs or protection codes for your objects, remember that users with amplified privileges are entitled to special access to objects throughout the system. For example, there is no way to stop a user with the BYPASS privilege from accessing your files. Users with GRPPRV privilege have the power to perform many system management functions for other members of their UIC group. Protection of your objects depends on the judgment of your security administrator in granting these privileges.

4.6.2 Using Control Access to Modify an Object Profile

Any user with control access to an object can change its protection code and ACL and thereby gain access to an object. For all object classes but files, control access also allows a user to modify the object's owner. To modify the owner of a file generally requires privilege (see Section 5.4.2).

You obtain control access in any of the following ways:

• You hold an identifier to which the object's ACL gives control access.
• You have the same UIC as the owner of the object.
• You qualify as a member of the system user category, and the object has an owner with a nonzero UIC. For example, you hold GRPPRV (with a matching group UIC) or SYSPRV. (Refer to Section 4.5 for a full description of system users.)
• You hold BYPASS privilege.

Sometimes object classes allow control access through other means. Refer to Section 4.6.3 and to the individual descriptions of classes in Chapter 5 for any special conditions that may apply.

4.6.3 Object-Specific Access Considerations

For some objects, access can be granted by a special privilege (beyond those listed in Section 4.6.1) or by an all-inclusive type of access. This is particularly true of a queue. A user with operator (OPER) privilege is granted all types of access to a queue. A user with manage access implicitly possesses the three other types of queue access: read, submit, and delete. Chapter 5 lists each object class with its access types and meanings and any special privilege.

4.7 Auditing Protected Objects

Whenever a process uses an object or modifies its security profile (see Section 4.2.4), the system can send an alarm to an operator terminal or write a message to the audit log file. By reading the log file, a security administrator can review system activity to see how protected objects are being used, when they are being used, and who is using them.

Exactly which type of information is reported through the auditing system depends on how the security administrator defines the site's requirements. If system administrators choose to have object use audited, they can enable auditing for the appropriate categories of events.

The operating system can filter security-related events and send system administrators messages only when objects are accessed in certain ways. Sites are often more interested in the privileged use of a file or the failure to access a file than in every file access. Such a site can request auditing messages whenever a process fails in accessing a file, but not when it is successful. The system can report how the process exercised, or failed to exercise, the right to access the object in the first place: through a protection code, an ACE, or a privilege.

4.7.1 Kinds of Events the System Audits

Each object class has its own auditing profile, described in Chapter 5, and so it is possible to receive more information on some classes of objects than on others. For any object, the system can send an auditing message whenever a user or application accesses the object or modifies its security elements. In some instances, the system can send a notification when a process creates an object, stops using it (deaccesses it), or deletes it.

4.7.2 Enabling Auditing for a Class of Objects

When you are auditing object access events, keep in mind that the operating system may check a user's right to an object several times during a single operation. A file operation, for example, can involve checks for both directory and file access. Before a user deletes a file, the system checks for delete access to the file and write access to the directory.

For this reason, it is best for a security administrator to enable auditing for all types of object access events. For example, to track all instances where a user tries to access a file but fails, a security administrator would use the /ENABLE=ACCESS=FAILURE=ALL qualifier to the SET AUDIT command.

For object classes that support deaccess auditing (for example, the file class), once a process gains access to an object, the system does not audit subsequent access attempts to the object unless the process attempts an operation that is incompatible with the access modes previously granted. When this occurs, the system performs an additional protection check that is audited. This access window continues until the object is deaccessed (for example, the file is closed).

4.7.3 Adding Security-Auditing ACEs

Rather than audit an entire class of objects, security administrators and users with control access to an object can single out a specific object for auditing by attaching an Alarm or Audit ACE to it (see Section 3.10.2). Although you can add an auditing ACE to any file that you own or have control access to, it is best to consult your security administrator before doing so. As with object classes, the security administrator has to enable the ACL auditing category before any auditing messages are generated.

	privacy and legal statement
6346PRO_008.HTML