[OpenVMS documentation]
[Site home] [Send comments] [Help with this site] [How to order documentation] [OpenVMS site] [Compaq site]
Updated: 11 December 1998

OpenVMS Guide to System Security


Previous Contents Index


Chapter 5
Descriptions of Object Classes

This chapter describes the unique features of each class of protected object: files, volumes, devices, and so on. Each class description contains information on the following topics:
Topic Description
Naming rules A summary of naming conventions for objects in the class.
Types of access Access types supported for the class. Boldface type indicates the abbreviation of an access type, such as R for read access.
Template profile The default profile applied to new objects of the class. Site security administrators can modify the default profiles. Use the SHOW SECURITY command to display current template settings.
Privilege requirements Privileges, if any, required for certain operations on the object.
Kinds of auditing performed Events that trigger an audit event message (assuming the event class is enabled).
Permanence of the object Storage of security profiles. Explains if the security elements are stored from one system startup to another and if so, where the elements are stored.

If a given topic does not apply to a class, the topic is omitted.

5.1 Capabilities

A capability is a resource to which a site controls access, using the standard access control mechanisms. The ability to execute vector instructions is a capability object. Only sites with a vector processor have such an object.

5.1.1 Naming Rules

The only valid name for a capability object is VECTOR.

5.1.2 Types of Access

The capability class supports the following types of access:
Use Gives a process the right to make use of the vector processor
Control Gives you the right to change the protection and ownership elements of the object

5.1.3 Template Profile

The capability class provides the following template profile:
Template Name Owner UIC Protection Code
DEFAULT [SYSTEM] S:U,O:U,G:U,W:U

Modifications to the VECTOR template take effect the next time you boot the system. If you want to change the elements of the VECTOR object after the system is booted, you must modify the object directly. For example:


$ SET SECURITY/CLASS=CAPABILITY/PROTECTION=(S:U,O:U,G:U,W) VECTOR

5.1.4 Kinds of Auditing Performed

The operating system can audit the following type of event:
Event Audited When Audit Occurs
Access The first time after image activation that the process uses a vector instruction

5.1.5 Permanence of the Object

The capability object's security profile needs to be reset each time the system starts up.

5.2 Common Event Flag Clusters

A common event flag cluster is a set of 32 event flags that enable cooperating processes to post event notifications to each other.

Event flags in the cluster can be set or cleared to indicate the occurrence of an event. All event flags are contained within clusters of 32 event flags, and each process has access to four clusters (numbered 0 through 3). Two of the clusters are local to a single process. Event flag clusters 2 and 3 are called common event flag clusters and are used for interprocess synchronization. A subject may be associated with up to two common event flag clusters. Each common event flag in a cluster is referenced by an event flag number.

5.2.1 Naming Rules

The name of the object is whatever character string was supplied as an argument to the Associate Common Event Flag Cluster system service ($ASCEFC). Remember that common event flag cluster names are qualified by your UIC group number.

5.2.2 Types of Access

The common event flag cluster class supports the following types of access:
Associate Gives a process the right to establish an association with the named cluster so the process can access event flags.
Delete Gives a process the right to mark a permanent event flag cluster for deletion with the Delete Common Event Flag Cluster ($DLCEFC) system service. The actual deletion occurs once all processes disassociate from the cluster.
Control Gives you the right to modify the protection elements of the common event flag cluster.

5.2.3 Template Profile

The common event flag cluster class provides one template profile. Although the template assigns an owner UIC of [0,0], this value is only temporary. As soon as the object is created, the operating system replaces a 0 value with the value in the corresponding field of the creating process's UIC.
Template Name Owner UIC Protection Code
DEFAULT [0,0] S:AD,O:AD,G:A,W

When the process creating the common event flag cluster supplies a prot argument to $ASCEFC that has a value of 1, then the system modifies the template so the process UIC is the owner, and the protection code denies group access.

5.2.4 Privilege Requirements

Creation of a permanent common event flag cluster requires the PRMCEB privilege. This privilege also grants delete access for permanent clusters.

5.2.5 Kinds of Auditing Performed

The system can audit the following types of events:
Event Audited When Audit Occurs
Creation When the first process to associate with a particular cluster calls $ASCEFC
Access Whenever subsequent callers to $ASCEFC associate with the cluster
Deaccess When a process calls $DACEFC or associates with another cluster or at image rundown
Deletion When the process calls $DLCEFC

5.2.6 Permanence of the Object

A common event flag cluster and its security profile need to be reset each time a system starts up.

5.3 Devices

A device is a peripheral, physically connected or logically known to a processor and capable of receiving, storing, or transmitting data. A device can be physical, like a disk or terminal, or it can be virtual, like a mailbox or pseudoterminal. Virtual devices are implemented entirely in software.

5.3.1 Naming Rules

You can use physical, logical, or generic names to refer to devices. In addition, if your system is part of a clustered system, certain devices are accessible to all members of the cluster. They have the following formats:

See the OpenVMS System Manager's Manual and the OpenVMS User's Manual for a full description of device names.

5.3.2 Types of Access

Devices can be shared and thus have concurrent users or be unshared and have a single user.

Shared devices support the following types of access:
Read Gives you the right to read data from the device
Write Gives you the right to write data to the device
Physical Gives you the right to perform physical I/O operations to the device
Logical Gives you the right to perform logical I/O operations to the device
Control Gives you the right to change the protection elements and owner of the device

Unshared devices support only read, write, and control access. The device driver rather than the operating system's security policy defines the access requirements for other types of operations.

5.3.3 Access Requirements for I/O Operations

Access requirements for I/O operations on devices can be quite complex. The following list explains access requirements for typical operations:

Table 5-1 show the access requirements for devices that are not file oriented.

Table 5-1 Access Requirements for Non-File-Oriented Devices
Functions Requiring Read Access
READHEAD READVBLK TTYREADALL
READPBLK REREADN TTYREADPALL
READLBLK REREADP  
READTRACKD READPROMPT  
Functions Requiring Write Access
WRITECHECK WRITELBLK WRITETRACKD
WRITECHECKH WRITEPBLK WRITEVBLK
WRITEHEAD WRITERET  

5.3.4 Template Profile

The device class provides the following template profiles:
Template Name Device Type Owner UIC Protection Code
BUS DC$_BUS [SYSTEM] S:RWPL,O:RWPL,G,W
CARDREADER DC$_CARD [SYSTEM] S:RWPL,O:RWPL,G,W
COMMUNICATION DC$_SCOM [SYSTEM] S:RWPL,O:RWPL,G,W
DEFAULT   [SYSTEM] S:RWPL,O:RWPL,G:RWPL,W:RWPL
DISK DC$_DISK [SYSTEM] S:RWPL,O:RWPL,G:R,W
MAILBOX DC$_MAILBOX [SYSTEM] S:RWPL,O:RWPL,G:RWPL,W:RWPL
PRINTER DC$_LP [SYSTEM] S:RWPL,O:RWPL,G,W
REALTIME DC$_REALTIME [SYSTEM] S:RWPL,O:RWPL,G:RWPL,W:RWPL
TAPE DC$_TAPE [SYSTEM] S:RWPL,O:RWPL,G:R,W
TERMINAL DC$_TERM [SYSTEM] S:RWPL,O:RWPL,G,W
WORKSTATION DC$_WORKSTATION [SYSTEM] S:RWPL,O:RWPL,G:RWPL,W:RWPL

5.3.5 Setting Up Profiles for New Devices

A device usually derives its security profile from the template profile associated with its device type; however, the template is often modified. The following list describes how the operating system assigns a profile to different types of devices:

5.3.6 Privilege Requirements

All logical or physical I/O to a spooled device requires privilege.

The LOG_IO privilege allows the user's process to execute the Queue I/O Request ($QIO) system service to perform logical-level I/O operations. LOG_IO privilege is also required for certain device-control functions, such as setting permanent terminal elements.

The PHY_IO privilege allows the user's process to execute the Queue I/O Request ($QIO) system service to perform physical-level I/O operations. The PHY_IO privilege also grants LOG_IO privilege.

To create a permanent mailbox or mark it for deletion requires PRMMBX privilege.

5.3.7 Kinds of Auditing Performed

The following types of events can be audited, provided the security administrator enables auditing for the appropriate event class:
Event Audited When Audit Occurs
Access For nonshareable devices, when the process calls $ASSIGN. For a shareable device, when the process calls $QIO.
Creation When a process creates a virtual device like a mailbox.
Deletion When a process deletes a virtual device like a mailbox.


Previous Next Contents Index

[Site home] [Send comments] [Help with this site] [How to order documentation] [OpenVMS site] [Compaq site]
[OpenVMS documentation]

Copyright © Compaq Computer Corporation 1998. All rights reserved.

Legal
6346PRO_009.HTML