OpenVMS Guide to System Security
5.10.1 Naming Rules
A volume name can be the volume label, the name of the device on which
the volume is mounted, or a user-specified logical name. Volume label
names can be from 0--12 characters in length.
5.10.2 Types of Access
The volume class supports the following types of access:
Gives you the right to examine file names and print and copy files on a
Gives you the right to modify or write to existing files on a volume.
Whether the subject may perform the operation on a specific file is
determined by the file's protection. To be meaningful, write access
requires read access.
Gives you the right to create files on a disk volume and to
subsequently modify them. Create access also requires read and write
Gives you the right to delete files on a disk volume, provided the user
has proper access rights at the directory and file level. Delete access
requires read access.
Gives you the right to change the protection and ownership elements of
5.10.3 Template Profile
The class provides the following template profile and assigns the
values during initialization. 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.
5.10.4 Privilege Requirements
Users with the VOLPRO privilege always have control access to a volume.
Mounting a file-structured volume as foreign requires VOLPRO privilege
or control access.
5.10.5 Kinds of Auditing Performed
All volume access can be audited, provided the security administrator
enables auditing for the Access event class.
||When Audit Occurs
During any file system operation
5.10.6 Permanence of the Object
The security profile for a volume object is saved in the master file
directory (MFD) of the disk as SECURITY.SYS.
The chapters in this part discuss the following topics:
Security for the System Administrator
This part of the manual also includes information on the following
- User privileges and who may need them (Appendix A)
- Default UIC-based protection of critical system files
- Guidelines for operating in a C2 security environment
- Examples of security alarm messages (Appendix D)
Managing the System and Its Data
This chapter explains how you, as security administrator, implement
security features of the OpenVMS operating system. It provides an
overview of security management, based on the security needs of a
commercial installation with average security needs. It discusses the
- Your role as security administrator
- Site security policies
- Tools for security administrators
- Account requirements for a security administrator
- Suggestions for training users
- Logging the activities of a new user
- Tasks to include in your weekly routine
Compaq recommends that you read the entire chapter and the three
chapters that follow before establishing any security measures. After
reading the chapters, you will better be able to decide which security
measures are appropriate for your site, and you will have the tools to
6.1 Role of a Security Administrator
Your role as security adminstrator is to implement and maintain the
organization's security policy. Some organizations include security
administrators in the development of the security policy; other
organizations charter security administrators to implement and maintain
an established policy. For an example of a company security policy, see
As security administrator (or officer), your job is to see that the
security policy is implemented and maintained. Regularly monitoring the
system for possible security violations and vulnerabilities is
absolutely necessary. Whenever you detect problems, you should see that
they are corrected.
Many times organizations divide the duties of computer administrators.
The security administrator monitors the system and reports problems,
and the system manager implements policy and manages the system. In
this management structure, the security administrator works in tandem
with the system manager. Some system managers choose to employ an
accounts clerk to set up user accounts and process the required
paperwork justifying the need for an account. This is always a highly
trusted individual who essentially acts as a co-system manager. With a
division of labor, it is critical for the system manager and security
administrator to communicate regularly. The security administrator
should report security problems to users or, if necessary, to system
managers or the accounts clerk so problems are corrected.
Another division of duties, common to many OpenVMS installations,
combines the roles of security administrator and system manager. One
person implements the security policy and maintains the system to meet
Secure system management, however it is organized, involves training
users, setting up accounts and passwords, protecting sensitive system
files and resources, and auditing and analyzing security-relevant
events. Learning how systems are used and recognizing
"normal" system activity are critical to secure management.
6.2 Site Security Policies
An organization's management usually establishes a brief security
policy for its employees to emphasize the behavior it expects of them.
For example, such a policy may state that employees should not give
away company data or share passwords.
The managers of divisions or computer sites develop the detailed
security policy. It is a written set of guidelines on the use of
passwords and system accounts, physical access to the computer systems,
communication devices, and computer terminals, and the types of
security-relevant events to audit. These security guidelines might be
followed by more specific statements applying to particular operating
The complexity of a security policy eventually depends on whether the
division has high, medium, or low security requirements. Chapter 1
provides a set of questions that can help an organization determine its
As an example, a site security policy often defines which company
employees have access to certain systems and the type of access
available to the personnel performing nonroutine tasks and development.
Sometimes a policy can provide an intricate set of rules for
determining system access. Table 6-1 presents the policy developed
by one division.
Table 6-1 Example of a Site Security Policy
Schedule for password changes.
Process for controlling minimum password length and expiration periods.
Schedule for system password changes.
Procedure to grant accounts on computer systems, for example, statement
of need, signature of requester, requester's manager, system manager,
or person setting up the account. (Accounts can never be shared.)
Procedure to deactivate accounts due to organizational changes, for
example, employee transfers or terminations.
Timetable for reauthorizing accounts, usually once every 6 to 12 months.
Directive to deactivate accounts that are not used on a regular basis.
Time periods for access.
Timetable for expiring accounts.
Procedure for requesting privileges that rigorously controls allocation.
Requirement to use nonprivileged accounts for privileged users
performing normal system activity.
Schedule for verifying inactive accounts.
List of approved security tools.
Security events to audit
Logins from selected or all sources.
Changes to authorization file records.
Other uses of privilege and system management actions.
Modifications to the known file list through the Install utility.
Modification to the network configuration database, using the network
control program (NCP).
Physical access to the computer room
A written list of authorized personnel with the reason for access
included. Typically, one person would be responsible for keeping this
Storage of a visitor log in a secure area.
Locked access doors and a documented procedure for assigning keys, key
cards, and combinations. (These access controls change periodically and
on transfer or termination of employees.)
Physical access to terminals and personal computers located outside the
Use of programs to log out terminals that have not been used for a
given period of time.
Security awareness programs for the organization (beyond computer
personnel); topics may include:
- Maintaining a list of approved software.
- Keeping desktops clear of hardcopy information relating to the
computer system, network passwords, and other system account
- Locking disks and file cabinets.
- Keeping diskettes inaccessible in or near workstations.
- Keeping keys out of open view.
List of authorized users.
Schedule for changing numbers periodically and procedures for notifying
users of number changes.
A policy to minimize publishing dialup numbers.
Policy about changing passwords periodically and when employees with
access are terminated.
Password protection, either in the modems or terminal servers, or
system passwords on host dialup ports.
Documentation available about:
- A dial-back system
- Details about the network
- Terminal equipment installed
- Terminal switching systems
- Details about all terminal devices connected to the network
- Details about all dialup equipment
Denial of access into privileged accounts if using passwords over
TCP/IP, LAT, or Ethernet links.
Use of authentication cards for network logins into privileged accounts.
6.3 Tools for Setting Up a Secure System
The following chapters describe how to set up a secure system according
to your security policy. The Authorize utility (AUTHORIZE) is the
primary tool for implementing system security. AUTHORIZE is described
fully in the OpenVMS System Management Utilities Reference Manual. The AUTOGEN command procedure, which you
use to modify the system parameters file, is described in the
OpenVMS System Manager's Manual and the OpenVMS System Management Utilities Reference Manual. Many DCL commands are also
important security tools. DCL commands are described in the
OpenVMS DCL Dictionary.
6.4 Account Requirements for a Security Administrator
You need an account with privileges to perform the tasks of a security
An administrator who reviews security violations and possible
vulnerabilities requires at least three privileges:
- SECURITY and AUDIT privileges to enable security auditing and to
set up security operator terminals
- READALL privilege to review the protection of files and resources
In many cases, a security administrator serves as both the security
administrator and the system manager. This person requires a full set
of privileges. The OpenVMS System Manager's Manual describes the necessary
characteristics of a system management account.
Example 6-1 illustrates a number of AUTHORIZE qualifiers appropriate
for a security administrator's account. Notice the following:
- The requirement that the automatic password
generator be used to change passwords.
- The use of a short password lifetime.
Measures 1 and 2 are important to protect the account because it
affords many valuable privileges and access rights.
- SECURITY, AUDIT, and READALL privileges allow
monitoring of the system but no modification. If you perform the tasks
of a system manager, then you would need an account with SYSPRV. With
SYSPRV, you can access protected objects by the system protection field
and change the owner UIC and protection. You can change an object's
protection to gain access to it.
In Example 6-1, any value not specified defaults to the value
provided by the default record in SYSUAF.DAT.
|Example 6-1 Sample Security Administrator's
$ SET DEFAULT SYS$SYSTEM
$ RUN AUTHORIZE
UAF> ADD RIRONWOOD/PASSWORD=VALTERSY/UIC=[001,100] -
_UAF> /DEVICE=SYS$SYSDEVICE/DIRECTORY=[RIRONWOOD] -
_UAF> /OWNER="Russ Ironwood"/ACCOUNT=SECURITY/FLAGS=GENPWD - (1)
_UAF> /PWDLIFETIME=30-/PWDMINIMUM=8 - (2)
identifier for value:[000001,000100] added to RIGHTSLIST.DAT
6.5 Training the New User
Teaching new users about system security is an important security tool.
It is important to involve users in security methods and goals; the
more they know about the system and how break-ins occur, the better
equipped they are to guard against them.
Include the following topics in your user training:
- What is the location of the user's account? Specifically, which
system, where is it located, what is the proper node name if on a
network, and, if the system is part of a cluster, what other nodes are
- Which terminals can be used for logging in, and where are they
- Is the account restricted with regard to local, dialup, remote,
interactive, network, or batch operations? If so, describe both
permitted use and restrictions.
- Can the account be accessed by dialing in? If so, provide the
access telephone number, and describe the procedure. Specify how many
retries are allowed and the maximum number of seconds allowed between
each retry before the connection is lost.
- Are system passwords implemented for any terminals that the user
may be using? If so, describe which terminals, how often the system
password is changed, and how the user can learn the new system password.
- What is the account duration? When will it expire? From whom should
the user request an extension?
- What is the user name? What identifiers are held by the user, if
any? What are the group and member numbers associated with the user?
- What password information is required? Specifically, what is the
initial password? Is the password locked? If the password is not
locked, how often must the password be changed? What is the minimum
length for the password? Is there a secondary password for this
account, and who will know it? Is the user free to select passwords, or
must they be automatically generated? See Section 3.12 for a checklist
of good practices for users.
- What is the default device and directory?
- What is the default protection?
- Are there quotas on disk usage? If so, what are the values?
- Are there restrictions on use? For example, are there certain days
or hours of the day that are suggested or enforced? Explain primary and
secondary days if applicable.
- Are there files or directories that are shared? If so, provide the
- Are there ACLs that affect the user? What identifiers does the user
need to know?
- Which privileges does the user hold and what do they mean?
- What is the command language interpreter?
- Which type of account is this: open, captive, restricted, or
- Which nodes permit proxy logins for this user, if any?
- What are the names of the queues the user may need to use?
- What actions should the user take to ensure physical site security,
such as locking up materials?
6.6 Logging a User's Session
While users are learning the system, you may choose to monitor terminal
sessions if the user performs an especially sensitive function, such as
accessing sensitive data or controlling a system operation. (Sometimes
users may choose to log their own sessions so they have a record of
their actions. If this is the case, they can use the command SET HOST
0/LOG interactively after their initial login.) This section describes
one method of logging users' sessions by setting up a restricted
account. Many third-party products provide other ways of monitoring
sessions that are more efficient. Regardless of the method you select,
you should check with your legal department to make sure this is
By using a special restricted account and appropriate command
procedures, you can enforce the logging of terminal sessions for
selected users. These users would need to log in to the restricted
account first and then log in to their own account. The restricted
account ensures that the session is logged.
The following example provides guidelines on how to set up the
restricted account (named USER_LOG in this example) and includes
samples of appropriate command procedures:
- Set up the restricted account USER_LOG as follows:
UAF> ADD USER_LOG /FLAGS=(RESTRICTED,DISMAIL,DISNEWMAIL)-
_UAF> DEV=SYS$SYSROOT: /DIR=[USER_LOG]-
_UAF> /NONETWORK /NOBATCH /UIC=[200,256]
- The SESSIONLOG.COM command procedure enables logging of the
$ ! SESSIONLOG.COM - log in to specified account with terminal session
$ ! logging enabled.
$ WRITE SYS$OUTPUT "Please log in to the account of your choice."
$ WRITE SYS$OUTPUT "Your terminal session will be recorded."
$ WRITE SYS$OUTPUT ""
$ ! Acquire the intended user name and save it in a temporary file. Use
$ ! it to name the log file, and pass it as the first line of input to
$ ! LOGIN.
$ READ/PROMPT="Username: " SYS$COMMAND USERNAME
$ PID = F$GETJPI (0, "PID")
$ OPEN/WRITE OUTPUT USERNAME'PID'.TMP
$ WRITE OUTPUT USERNAME
$ CLOSE OUTPUT
$ DEFINE/USER SYS$INPUT USERNAME'PID'.TMP
$ SET HOST 0 /LOG='USERNAME'.LOG
$ DELETE USERNAME'PID'.TMP;0
- Set up each account for which session auditing is to be enforced.
The following command sets up the account for user Smith:
UAF> MODIFY SMITH /FLAGS=RESTRICTED /NOLOCAL /NODIALUP -
Because the restricted login command procedure ensures that the
login is coming from the USER_LOG account using a SET HOST command, the
session is logged.
- You may also want to disable batch and network access for each
user account to allow only local logins from the USER_LOG account. For
UAF> MODIFY SMITH/FLAGS=RESTRICTED/NOLOCAL/NODIALUP/NOBATCH -
- The following CHECKLOG.COM command procedure verifies that the
user is logging in to the USER_LOG account. For this procedure to work
correctly, you must have enabled DECnet proxy accounts as described in
$ ! CHECKLOG.COM - ensure that the account is being logged in to
$ ! the USER_LOG account.
$ IF F$MODE () .NES. "INTERACTIVE" THEN EXIT
$ ! Verify that the connection originated from the local node and
$ ! from the USER_LOG account.
$ IF F$LOGICAL ("SYS$NODE") .EQS. F$LOGICAL ("SYS$REM_NODE")-
_$ .AND. F$LOGICAL ("SYS$REM_ID") .EQS. "USER_LOG"-
_$ THEN GOTO OK
$ WRITE SYS$OUTPUT "You may log in to this account only with ",-
_$ "the USER_LOG account."
$ ! When the login has been verified, enable Ctrl/Y to
$ ! release the account, invoke the user's LOGIN.COM, and turn
$ ! control over to the user.
$ SET CONTROL_Y
$ IF F$SEARCH ("LOGIN.COM") .EQS. "" THEN EXIT