OpenVMS Guide to System Security
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
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:
||When Audit Occurs
For nonshareable devices, when the process calls $ASSIGN; for a
shareable device, when the process calls $QIO
When a process creates a virtual device like a mailbox
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 system starts up.
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
includes 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:
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.
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.
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.
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.
Gives you the right to change the protection code and ACL. You need to
satisfy one of the following conditions to change the owner:
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
- 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
- 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, you must have read or execute access to the
directory containing the file. 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.
You can 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.
- File ownership changes
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
- 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.
126.96.36.199 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 188.8.131.52 for a description of how resource identifiers can own
files and directories.
184.108.40.206 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
- 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 -
- 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
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
Use the DCL command SHOW PROTECTION to display the default process
- 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
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
220.127.116.11 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 18.104.22.168 and Section 22.214.171.124 explain how a security profile is
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:
||When Audit Occurs
When a process opens, reads, writes, or executes a file or inquires
about its attributes
When a process creates a file
When a process closes a file
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.
The OpenVMS operating system solves the problem of disk scavenging with
the combination of the two following techniques:
- Overwriting disk blocks before they are allocated
- Setting a high-water mark on allocated blocks
126.96.36.199 Overwriting Disk Blocks
A security administrator or user can apply an erasure pattern to
individual files on a volume or to a complete volume. An erasure
pattern is a repeated sequence of bits written over a file when the
file is deleted or purged.
The security administrator can ensure that every block on a volume
starts off with the erasure pattern by specifying the /ERASE qualifier
when the volume is initialized, as follows:
INITIALIZE/ERASE device-name[:] volume-label
If the volume is mounted, the security administrator can automatically
apply the erasure pattern to the space occupied by a file when it is
deleted by specifying the /ERASE_ON_DELETE qualifier, as follows:
SET VOLUME/ERASE_ON_DELETE device-spec[:]
Note that this technique has no effect on existing files.
Alternatively, the security administrator may ask users to specify the
erasure pattern on a file-by-file basis by using the /ERASE qualifier
when entering the DCL commands SET FILE, DELETE, and PURGE.
Security administrators can also write an erase routine by using the
$ERAPAT system service. The routine specifies to the system the erasure
pattern and number of passes to be used to erase disk blocks.
188.8.131.52 Setting a High-water Mark
When the operating system allocates disk blocks for a file, it
automatically sets a high-water mark. The high-water
mark indicates how far the file has been written in its allotted space
on the disk. All blocks in the file up to the high-water mark are
guaranteed to have been written since they were allocated to the file.
Users are not permitted to read beyond the high-water mark and thus
cannot read stale data that they did not actually write.
A more conservative but costly technique is to erase all disk blocks
before allocation. The erase-on-allocate technique is
used when the file is open allowing any form of shared access or
nonsequential access. When blocks are erased on allocation, the file's
high-water mark is set to point to the end of the newly allocated and
By default, high-water marking is enabled when the volume is
initialized. The security administrator can disable high-water marking
for a specific volume by using the DCL command SET
184.108.40.206 Accessibility of Data in a File
Once the file system allocates disk blocks for a file, users can read
or write to them at any time. The high-water mark identifies the
physical end of file, beyond which the user cannot read. However, an
application can reposition the logical end-of-file mark and leave data
in the area between the logical and the physical end of the file. Any
block of file data can later be read, regardless of the logical
An application largely determines how allocated disk blocks are
managed. For example, OpenVMS RMS services shorten a sequential file by
resetting the logical end-of-file position to the beginning of the
current record. It does not deallocate space between the end-of-file
position and the physical end of the file, nor does it overwrite the
records between the end-of-file position and the physical end of the
file with an erase pattern.
Thus, blocks written to a file can remain available regardless of the
end-of-file mark. If you want to erase the data between the logical end
of the file and the physical end of the file, your application program
must overwrite the data you want deleted. On OpenVMS systems, a common
way to accomplish this is to create a new version of the file using the
DCL command COPY.
5.4.8 Suggestions for Optimizing File Security
Use the following precautions to protect your files and directories:
- Purge your files regularly. Delete unnecessary files. This keeps
your directories to a minimum and simplifies the task of regularly
checking the protection and ownership on your files.
- Use the DCL command DIRECTORY/SECURITY regularly to monitor the
ownership, protection code, and ACLs on your files. A user who succeeds
in obtaining sufficient privilege may change the protection or
ownership on your files, allowing access immediately and in the future.
If you perform these checks frequently, you can detect and report
unexplained changes in file protection or ownership.
- Pay special attention to the protection on your mail files;
normally, they should be accessible only to you and the system (for
mail delivery and backups).
- When you place ACLs on your files, be sure you know exactly which
users hold the identifiers you have specified. (This generally requires
consultation with your site security administrator.)
- Follow your site security administrator's recommendations to
prevent disk scavenging. You may be requested to use the /ERASE
qualifier on the SET FILE, DELETE, and PURGE commands for some or all
of your files.
- Always protect files and directories that contain command
procedures and executable programs. Carefully control the granting of
write access to these directories and files. This is particularly
important if you have any of the more powerful privileges or access to
Do not run a command procedure or program given to you by another user
unless you inspect it. Inspect a program or procedure to see if it
tries to exercise your special privileges or access sensitive files.
Test the software in an unprivileged account. Programs or command
procedures offered under one guise, when actually intended to penetrate
your defenses and disrupt your system security, are sometimes called
Trojan horse programs.
5.5 Global Sections
OpenVMS memory management services allow processes to communicate
through shared memory pages called global sections. Using global
sections, two or more processes can map the same page into their
individual virtual address spaces, thereby sharing the same page of
code or data.
A global section can provide access to a disk file (called a
file-backed global section), provide access to dynamically created
storage (called a page file-backed global section), or provide access
to specific physical memory (called a page frame number [PFN] global
section). A global section object may be either temporary or permanent.
The operating system supports two types of global section objects:
- Group global sections are shareable memory
sections potentially available to all processes in the same group.
- System global sections are shareable memory
sections potentially available to all processes in the system.