HP OpenVMS Systems Documentation
OpenVMS Guide to System Security
|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.
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|
The capability class provides the following template profile:
|Template Name||Owner UIC||Protection Code|
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
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|
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
|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.|
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|
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
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|
A common event flag cluster and its security profile need to be reset
each time a system starts up.
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
5.3.2 Types of Access
Devices can be shared and thus have concurrent users or be unshared and have a single user.
|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
Table 5-1 show the access requirements for devices that are not file oriented.
|Functions Requiring Read Access|
|Functions Requiring Write Access|
The device class provides the following template profiles:
|Template Name||Device Type||Owner UIC||Protection Code|
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:
In OpenVMS Version 7.2-1 and earlier, all pseudo-terminal (FT) device protection codes were set by the driver to (S:RWLP,O:RWLP,G,W). In OpenVMS Version 7.3 and later, only device FTA0 is set to this forced protection. This allows the system manager the option of modifying the FTA0 device protection later in the boot process. This new protection is inherited from FTA0 by any new FT devices created thereafter (as well as other settings originating from the SECURITY class DEVICE TERMINAL template profile, such as ACLs).
A system manager can modify FTA0 manually, or change the SYSTARTUP_VMS.COM command procedure. For example:
If the device protection for FTA0 is left unmodified, the behavior is unchanged from versions of OpenVMS prior to Version 7.3. That behavior is that all terminals except FT pseudo-terminal devices inherit their device protection and other security characteristics from the TERMINAL template profile. All FTA pseudo-terminal devices inherit their protection from FTA0, which by default is set to (S:RWLP,O:RWLP,G,W). Other settings, such as ACLs, are inherited from the TERMINAL template profile. This ensures compatibility with existing applications.