HP OpenVMS Guide to System Security: OpenVMS Version 8.4 > Chapter 5 Descriptions of Object Classes
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 or 5 (ODS-2 or ODS-5) 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. “Profile Assignment” describes the rules the operating system applies in assigning a
A file specification is a string of 1 to 255 characters.
See the HP OpenVMS User's Manual for a
Types of Access
The file class supports the following types of
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
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.
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
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.
The following conditions apply to file access:
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.
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.
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
See “Setting Defaults for a Directory Owned by a Resource Identifier” for a description of how resource
identifiers can own files and directories.
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
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
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 “Providing a Default Protection Code for a Directory Structure” for an example.) If any ACE in the directory's ACL has the
Default attribute, then the file inherits that ACE as well. (See the “Establishing an Inheritance Scheme for Files” 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
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
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.
“Rules for Assigning Ownership” and “Rules for Assigning a Protection Code and ACL” explain how a security profile is
Kinds of Auditing Performed
The following types of events can be audited,
provided the security administrator enables auditing for the appropriate
| Event Audited|| 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
process deletes a file
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
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,
SET VOLUME/ERASE_ON_DELETE device-spec[:]
Note that this technique has no effect on existing
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.
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 erased space.
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:
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 end-of-file mark.
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.
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 sensitive files.
|CAUTION: 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. |