Updated: 11 December 1998 |
OpenVMS Guide to System Security
Previous | Contents | Index |
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: ... |
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:) |
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: |
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) [...]*.*;* |
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:
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:
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.
Previous | Next | Contents | Index |
Copyright © Compaq Computer Corporation 1998. All rights reserved. Legal |
6346PRO_008.HTML
|