HP OpenVMS Systems Documentation
OpenVMS Guide to System Security
4.5.2 Types of Access in a Protection Code
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.
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:
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.
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:
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:
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:
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.
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:
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:
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.
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:
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:
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:
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).
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.
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.
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:
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.
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).
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.
For some objects, access can be granted either 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.
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.
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.
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).
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.