OpenVMS Guide to System Security

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

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:

Most physical device names consist of three parts:
- A device code (dd), which represents the hardware device type.
- A controller designator (c), which identifies the hardware controller to which the device is attached.
- The unit number (U), which uniquely identifies a device on a particular controller.
The maximum length of the device name field, including the controller and the unit number, is 15 characters.
Logical device names equate the somewhat cryptic physical device name to a short, meaningful name. You can use these logical device names, rather than the physical device names, to refer to devices.
A generic device name consists of the device code and omits the specific controller or unit number.
A cluster device name includes the name of the node to which the device is attached and the physical device name, separated by a dollar sign ($).

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:

Assigning a channel with $ASSIGN Assigning a channel to a nonspooled, nonshareable device requires read access, write access, control access, or any combination. Assigning a channel to a shareable device has no access requirement.
Allocating a device with $ALLOC Allocating any device with $ALLOC requires read, write, or control access.
$QIO to spooled devices Access is handled as described for OpenVMS mounted volumes. See the next list item, $QIO to file-oriented devices.

$QIO to file-oriented devices: disks and tapes With file-oriented devices, logical I/O and physical I/O functions have common elements. Any logical I/O function requires physical or logical access plus read access to read a block (READLBLK) or write access to write a block (WRITELBLK). Any physical I/O function requires physical access plus either read access to read a block (READPBLK) or write access to write a block (WRITEPBLK). Logical and physical I/O also require LOG_IO and PHY_IO privileges, respectively. Beyond this, access requirements depend on how the volume is mounted:

OpenVMS supported volumes Any virtual I/O to the volume has the same access requirements as the File or Volume class (see Section 5.4 and Section 5.10).
Volumes mounted foreign (/FOREIGN) Virtual read and write functions are converted to logical I/O. All other functions are not processed by the operating system and are sent to the device driver for processing. Physical I/O functions also require PHY_IO privilege.
Devices without a mounted volume Access to devices without mounted volumes requires privilege.

$QIO to devices that are not file-oriented With non-file-oriented devices, OpenVMS converts virtual read and write I/O requests to logical I/O before processing them. Other kinds of access requests are not processed by OpenVMS; instead, the request is passed to the device driver for processing.
In general, access requirements for devices that are not file oriented depend on whether the device is shareable or nonshareable:

Shareable devices With shareable devices, such as mailboxes, any virtual I/O function other than READVBLK/WRITEVBLK is handled by the system I/O driver program. Any logical I/O function requires privilege or logical access to the device. Any physical I/O function requires privilege or physical access to the device.

Unshareable devices With unshareable devices, such as terminals or printers, the operating system checks only for read or write access to perform virtual and logical I/O functions. Any physical I/O function requires privilege.
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

**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

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:

Devices created during system configuration Devices introduced during system configuration with the system commands CONNECT and LOAD (for example, pseudodevices and workstations) take their profiles from the template appropriate for the device type.
Disks and tapes Disk or tape devices take their profile from the DISK or TAPE template profile, respectively. Once the device is visible within a cluster, its profile, with any modifications, is retained across system restarts. Changes to the DISK or TAPE template profile after a device has its security profile do not apply to that device; therefore, it is necessary to reset the specific object profile by using the DCL command SET SECURITY (see Section 4.2.4).
Devices cloned from template devices Devices cloned from template devices (for example, Ethernet devices) assume the security profile of the template device from which they are cloned. Template devices are loaded during the autoconfiguration process; at this time, their profile is taken from the profile template appropriate for the device.
Mailboxes Mailbox devices assume a modified version of the MAILBOX template profile. The system modifies the template so the UIC of the creating process becomes the owner and the protection code is set to the value of the promsk argument to the Create Mailbox ($CREMBX) system service (provided the value is nonzero).
To maintain compatibility with earlier versions of the operating system, the MAILBOX template has a protection code of 0 (allowing all access). Some applications may need a more restrictive default than the template provides. If you do choose to restrict mailbox access, be aware that the more restrictive access can cause applications to fail in ways that are difficult to diagnose.
Terminals
Terminal devices assume a modified version of the TERMINAL template profile. When a user logs in on a terminal, the operating system modifies the profile so the owner becomes the UIC of the process logging in to the terminal. The original security profile for the terminal is restored when the user logs out.

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.

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.

5.3.8 Permanence of the Object

The profile of clusterwide disks and tapes is stored in the object database VMS$OBJECTS.DAT, but other object profiles have to be reset each time the systems starts up.

5.4 Files

A file is a named array of fixed-size (512-byte) data blocks with an associated set of attributes. In OpenVMS systems, the file class include both data files and directory files. The operating system provides full security protection for individual disk files stored on Files-11 On-Disk Structure Level 2 (ODS-2) volumes. Tape files are collectively protected by the protection code on the volume but are not protected on an individual basis.

The file object differs from other protected objects in one important way: because files provide more flexibility than any other object class, files do not acquire their profiles from a template. Section 5.4.5 describes the rules the operating system applies in assigning a profile.

5.4.1 Naming Rules

A file specification is a string of 1 to 255 characters. See the OpenVMS User's Manual for a full description.

5.4.2 Types of Access

The file class supports the following types of access:

Read Gives you the right to read, print, or copy a disk file. With directory files, read access gives you the right to read or list a file and use a file name with wildcard characters to look up files. Read access implies execute access.

Write Gives you the right to write to or change the contents of a file but not delete it. Write access allows modification of the file elements that describe the contents of the file. Write access allows creation of a new version of an existing file's primary name. With directory files, write access gives you the right to make or delete an entry in the catalog of files.

Execute Gives you the right to execute a file that contains an executable program image or DCL command procedure. With a directory file, execute access gives you the right to look up files whose names you know.

Delete Gives you the right to delete a file. To delete a file, you must have delete access to the file and write access to the directory that contains the file. To remove or rename a file's primary name also requires delete access.

Control Gives you the right to change the protection code and ACL. You need to satisfy one of the following conditions to change the owner:

Hold both the old and the new owner identifier.
Hold the Resource attribute to the identifier that owns the object while also being allowed control access to the object through an ACL on the object.
Qualify as a system user, hold SYSPRV or BYPASS privilege, or hold a UIC that matches that of the owner of the volume containing the file or directory.
Hold the GRPPRV privilege while also holding a UIC in the same group as the object owner.

5.4.3 Access Requirements

The following conditions apply to file access:

General rules To access a file, you must have permission to access the file and the volume on which it resides. When attempting to access a file by name, read or execute access to the directory containing the file is also required. An access check of the volume is required before either a directory or a file access is considered. The protection of a directory file can restrict access to files in the directory, so even though a group of users has access to a file, they can be prevented from accessing it by name if they lack proper access to the directory in which the file is located.

Note
It is possible to access a file by its file identifier. When users do so, they bypass the directory file protection. Therefore, you must not rely entirely on directory file protection to control access to a file.
For write access To write to a file, the operating system requires that you have both read and write access.
Changing file ownership To change the ownership of a file, you must have control access and hold both the old and new identifiers with the Resource attribute. (Your own UIC identifier always carries the Resource attribute.)

5.4.4 Creation Requirements

Before you can create a file, the operating system checks to see that you have satisfied the following conditions:

You must have adequate disk space. This includes both available disk blocks and sufficient disk quota (assuming quotas are enabled).
You have read and write access to the previous file version. You must also have delete access to the oldest file version if the file has a nonzero version limit and the new version would exceed this number.
You have write access to the directory where the file is being created.
You have read, write, and create access to the volume on which the file is to be stored.

5.4.5 Profile Assignment

The new file obtains its owner, protection code, and ACL from a number of sources. The ownership assignment of a new file is done independently of protection and ACL.

5.4.5.1 Rules for Assigning Ownership

If any of the following conditions are true, then you can assign an identifier as the owner of a file:

The identifier matches your process UIC.
You hold the identifier with the Resource attribute.
You hold GRPPRV privilege and the identifier's group number matches your UIC group.
You hold SYSPRV privilege.

A file receives its owner identifier from the first applicable source that you are allowed to assign:

The explicit assignment of an owner at creation with the /OWNER_UIC qualifier to the CREATE or COPY command
The previous version
The parent directory
The process UIC

See Section 8.8.1.2 for a description of how resource identifiers can own files and directories.

5.4.5.2 Rules for Assigning a Protection Code and ACL

The sources of a new file's protection code and ACL are similar to those of ownership and are considered in the same order. The system assigns a file's protection code and ACL from one of the following sources:

The explicit assignment of elements at creation
You can create a file with the CREATE command or the COPY command. You use the CREATE/DIRECTORY command in the case of a directory.
To assign a protection code when creating a file, add the /PROTECTION qualifier to the COPY or CREATE command. After creating the file, you can use the SECURITY/ACL command to add an ACL.
For example, the following command copies a file from the device USE1 to the default disk directory. The protection code defines the protection for the newly created file PAYSORT.DAT so that users with system UICs can read and write to the file. The owner has all types of access, and other users in the owner's group can read and write to the file. All other users have no access through the protection code.
```
$ COPY USE1:[PAYDATA]PAYROLL.DAT  PAYSORT.DAT -
_$ /PROTECTION=(SYSTEM:RW,OWNER:RWED,GROUP:RW,WORLD)
```
The profile of the previous version of the file, if one exists
Whenever you create a new version of the file, the new version is created with the protection code and ACL of the earlier version (unless, of course, you make an explicit assignment).
A Default Protection ACE and Default ACL on the parent directory
Without either an explicit assignment or a previous version of a file, the operating system looks at the directory where the file is being created.
With data files, the system looks for a Default Protection ACE and assigns the protection code specified by that ACE. (See Section 4.5.6 for an example.) If any ACE in the directory's ACL has the Default attribute, then the file inherits that ACE as well. (Refer to Section 4.4.7 for an example.)
With directory files, the system assigns the protection code of the parent directory, less any delete access. If the directory happens to be a top-level directory, the protection is taken from the master file directory (MFD). Newly created subdirectories inherit the ACL of the parent directory, even ACEs with the Default attribute. Only ACEs with the Nopropagate attribute are omitted.
The UIC and protection defaults of the process issuing the command
If the directory ACL does not have a Default Protection ACE, the default process protection is used. The system parameter RMS_FILEPROT establishes this value, and the operating system assigns it to your process during login. However, the value derived at login may be changed with the DCL command SET PROTECTION/DEFAULT. (For example, you can put this command in your login command procedure to set default protection.) Use the DCL command SHOW PROTECTION to display the default process protection.
One of the above with provision for the user creating the file When you create a file in a directory owned by a resource identifier and you hold the identifier with the Resource attribute, the new file inherits its protection code and ACL in the same way as any other file.
The operating system modifies the file's ACL in some cases to provide the creator with access to the new file. If the directory ACL has a Creator ACE, that ACE defines the access the creator has to the file. If the Creator ACE specifies no access, no additional ACE is created. Without such an ACE, the operating system adds an ACE to the file's ACL that gives the creator control access plus the access specified in the owner field of the file's protection code.

5.4.5.3 Using the COPY and RENAME Commands

The output file of a COPY command is treated as a newly created file and so is assigned a new security profile. The security profiles of the input files are immaterial.

However, a renamed file by default retains its existing security profile. To assign a new security profile, as if the file were newly created, use the DCL command RENAME/INHERIT_SECURITY. This causes the file to be assigned a security profile.

Section 5.4.5.1 and Section 5.4.5.2 explain how a security profile is assigned.

5.4.6 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 When a process opens, reads, writes, or executes a file or inquires about its attributes

Creation When a process creates a file

Deaccess When a process closes a file

Deletion When a process deletes a file

Event Audited	When Audit Occurs
Access	When a process opens, reads, writes, or executes a file or inquires about its attributes
Creation	When a process creates a file
Deaccess	When a process closes a file
Deletion	When a process deletes a file

5.4.7 Protecting Information When Disk Space Is Reassigned

Ordinary file protection mechanisms control who can access a file, but they do not address the problem of protecting old data that remains on disk after a file is deleted.

When a file is deleted, its header is removed from the directory, but its contents remain intact on disk until it is overwritten. Because data exists on a disk, it is necessary to protect deleted or purged file information from disk scavenging.

  6346P007.HTM
  OSSG Documentation
  22-NOV-1996 13:04:59.87

Legal

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

Read	Gives you the right to read, print, or copy a disk file. With directory files, read access gives you the right to read or list a file and use a file name with wildcard characters to look up files. Read access implies execute access.
Write	Gives you the right to write to or change the contents of a file but not delete it. Write access allows modification of the file elements that describe the contents of the file. Write access allows creation of a new version of an existing file's primary name. With directory files, write access gives you the right to make or delete an entry in the catalog of files.
Execute	Gives you the right to execute a file that contains an executable program image or DCL command procedure. With a directory file, execute access gives you the right to look up files whose names you know.
Delete	Gives you the right to delete a file. To delete a file, you must have delete access to the file and write access to the directory that contains the file. To remove or rename a file's primary name also requires delete access.
Control	Gives you the right to change the protection code and ACL. You need to satisfy one of the following conditions to change the owner: Hold both the old and the new owner identifier. Hold the Resource attribute to the identifier that owns the object while also being allowed control access to the object through an ACL on the object. Qualify as a system user, hold SYSPRV or BYPASS privilege, or hold a UIC that matches that of the owner of the volume containing the file or directory. Hold the GRPPRV privilege while also holding a UIC in the same group as the object owner.