VSI OpenVMS Guide to System Security

Document Number: DO–DSYSEC–01A
Publication Date: December 2019
Software Version:
VSI OpenVMS I64 Version 8.4-1H1
VSI OpenVMS Alpha 8.4-2L1
and 8.4-2L2

Preface

1. About VSI

VMS Software, Inc. (VSI) is an independent software company licensed by Hewlett Packard Enterprise to develop and support the OpenVMS operating system.

VSI seeks to continue the legendary development prowess and customer-first priorities that are so closely associated with the OpenVMS operating system and its original author, Digital Equipment Corporation.

2. Intended Audience

This guide is designed for users and for administrators responsible for protecting operating systems from tampering, observation, or theft of services by unauthorized users. The term security administrator is used in this guide to refer to the person or persons responsible for system security.

3. Document Structure

This guide contains the following information:
  • Chapter 1 discusses levels of security requirements and describes three sources of security failures.

  • Chapter 2 introduces the reference monitor concept of security design and provides an overview of the operating system's security features.

  • Chapter 3 provides information for the general user about the login and logout processes and the responsible use of passwords.

  • Chapter 4 and Chapter 5 describe object protection features in detail.

  • Chapter 6 describes the general tasks of a security administrator.

  • Chapter 7 describes methods of controlling system access.

  • Chapter 8 describes methods of controlling access to system data and resources.

  • Chapter 9 describes how to use encryption, which transforms a file into unrecognizable, unintelligible data, even if someone manages to gain access to it.

  • Chapter 10 describes security-auditing features.

  • Chapter 11 describes how to recognize when a system is under attack and how to protect and defend your system.

  • Chapter 12 describes security-related actions specific to clustered systems, such as setting up common system files and synchronizing authorization data.

  • Chapter 13 describes security considerations for systems using networking.

  • Chapter 14 describes how to set up and manage protected subsystems.

  • Appendix A provides a summary of all the user privileges available on the operating system and describes who may need them.

  • Appendix B lists the protection codes and ownership that VSI provides for critical system files.

  • Appendix C provides examples of security alarm messages.

4. Related Documents

The VSI OpenVMS Guide to System Security assumes you are familiar with the reference material in the VSI OpenVMS System Management Utilities Reference Manual pertaining to the following security-related utilities:
  • Access control list editor (ACL editor)

  • Accounting utility

  • Audit Analysis utility

  • Authorize utility

  • Backup utility

  • System Management (SYSMAN) utility

You might find helpful the amplified security information in the following manuals:
  • VSI OpenVMS DCL Dictionary

  • VSI OpenVMS System Manager's Manual

  • VSI OpenVMS Cluster Systems Manual

5. VSI Encourages Your Comments

You may send comments or suggestions regarding this manual or any VSI document by sending electronic mail to the following Internet address: . Users who have OpenVMS support contracts through VSI can contact for help with this product.

6. OpenVMS Documentation

The full VSI OpenVMS documentation set can be found on the VMS Software Documentation webpage at https://docs.vmssoftware.com/.

7. Typographical Conventions

The following conventions are also used in this manual:
ConventionMeaning

Ctrl/x

A sequence such as Ctrl/x indicates that you must hold down the key labeled Ctrl while you press another key or a pointing device button.

PF1 x

A sequence such as PF1 x indicates that you must first press and release the key labeled PF1 and then press and release another key or a pointing device button.

...
A horizontal ellipsis in examples indicates one of the following possibilities:
  • Additional optional arguments in a statement have been omitted.

  • The preceding item or items can be repeated one or more times.

  • Additional parameters, values, or other information can be entered.

.
.
.

A vertical ellipsis indicates the omission of items from a code example or command format; the items are omitted because they are not important to the topic being discussed.

( )

In command format descriptions, parentheses indicate that you must enclose the options in parentheses if you choose more than one.

[ ]

In command format descriptions, brackets indicate optional choices. You can choose one or more items or no items. Do not type the brackets on the command line. However, you must include the brackets in the syntax for OpenVMS directory specifications and for a substring specification in an assignment statement.

|

In command format descriptions, vertical bars separate choices within brackets or braces. Within brackets, the choices are options; within braces, at least one choice is required. Do not type the vertical bars on the command line.

{ }

In command format descriptions, braces indicate required choices; you must choose at least one of the items listed. Do not type the braces on the command line.

bold text

Bold text represents the introduction of a new term. It also represents the name of an argument, an attribute, or a reason.

italic text

Italic text indicates important information, complete titles of manuals, or variables. Variables include information that varies in system output (Internal error number), in command lines (/PRODUCER= name), and in command parameters in text (where dd represents the predefined code for the device type).

UPPERCASE TEXT

Uppercase text indicates a command, the name of a routine, the name of a file, or the abbreviation for a system privilege.

Monospace type

Monospace type indicates code examples and interactive screen displays.

In the C programming language, monospace type in text identifies the following elements: keywords, the names of independently compiled external functions and files, syntax summaries, and references to variables or identifiers introduced in an example.

-

A hyphen at the end of a command format description, command line, or code line indicates that the command or statement continues on the following line.

numbers

All numbers in text are assumed to be decimal unless otherwise noted. Nondecimal radixes—binary, octal, or hexadecimal—are explicitly indicated.

Chapter 1. Understanding System Security

Effective operating system security measures help prevent unauthorized access and theft of computer time and any kind of sensitive information, such as marketing plans, formulas, or proprietary software. These measures can also protect equipment, software, and files from damage caused by tampering.

This chapter provides security administrators with an overview of security measures available with the operating system.

1.1. Types of Computer Security Problems

On any system there can be two types of users: authorized and unauthorized. Any person authorized to use the computer system has the right to access the system and its resources according to the authorization criteria set up by the site security administrator. Usage criteria may include the time of day, types of logins, use of different resources like printers and terminals, and so on. Unauthorized users have no right to use the system at all or only at a given time of day, or they have no right to use certain system resources.

On a computer system, security breaches usually result from one of four types of actions:
  • User irresponsibility refers to situations where the user purposely or accidentally causes some noticeable damage. One example would be a user who is authorized to access certain files making a copy of a key file to sell.

    There is little that an operating system can do to protect sites from this source of security failure. The problem frequently lies in application design deficiencies or inconsistent use of available controls by users and the security administrator. Sometimes the failure to enforce adequate environmental security unwittingly encourages this type of security problem.

    Even the best security system will fail if implemented inconsistently. This, along with the failure to motivate your users to observe good security practices, will make your system vulnerable to security failures caused by user irresponsibility. Chapter 3 discusses what users can do to help maintain system security.

  • User probing refers to situations where a user exploits insufficiently protected parts of the system. Some users consider gaining access to a forbidden system area as an intellectual challenge, playing a game of user versus system. Although intentions may be harmless, theft of services is a crime. Users with more serious intent may seek confidential information, attempt embezzlement, or even destroy data by probing. Always treat user probing seriously.

    The system provides many security features to combat user probing. Based on security needs, the security administrator implements features on either a temporary or permanent basis. See Chapter 4 for information on protecting data and resources with protection codes and access control lists.

  • User penetration refers to situations where the user breaks through security controls to gain access to the system. While the system has security features that make penetration extremely difficult, it is impossible to make any operating system completely impenetrable.

    A user who succeeds in penetrating a system is both skilled and malicious. Thus, penetration is the most serious and potentially dangerous type of security breach. With proper implementation of the OpenVMS security features, however, it is also the rarest security breach, requiring unusual skills and perseverance.

  • Social engineering refers to situations in which an intruder gains access to a system not by technical means, but by deceiving users, operators, or administrators. Potential intruders may impersonate authorized users over the phone. Potential intruders may request information that gains them access to the system, such as telephone numbers or passwords, or they may request an unwitting operator to perform some action that compromises the security of the system.

    As the technical security features of operating systems have strengthened in recent years, social engineering has been a factor in a growing percentage of security incidents. Operator training, administrative procedures, and user awareness are all critical factors to ensure that access is not inadvertently granted to unauthorized persons.

The following chapters explain how to avoid these problems:
  • Chapter 8 explains how to augment the protection of system files and resources.

  • Chapter 7 describes the intrusion detection system and how to set its parameters.

  • Chapter 10 explains how to monitor system activity and be notified by malicious activity.

  • Chapter 11 suggests how to handle system intrusions.

  • Chapter 3 and Chapter 6 list topics to include in your site training programs.

1.2. Levels of Security Requirements

Each site has unique security requirements. Some sites require only limited measures because they are able to tolerate some forms of unauthorized access with little adverse effect. At the other extreme are those sites that cannot tolerate even the slightest probing, such as strategic military defense centers. In between are many commercial sites, such as banks.

While there are many considerations in determining your security needs, the questions in Table 1.1 can get you started. Your answers can help determine the levels of your security needs. Also refer to Section 6.2 for a more specific example of site security requirements.
Table 1.1. Event Tolerance as a Measure of Security Requirements

Question: Could you tolerate the following event?

Level of Security Requirements Based on Toleration Responses

Low

Medium

High

A user knowing the images being executed on your system

Y

Y

N

A user knowing the names of another user's files

Y

Y

N

A user accessing the file of another user in the group

Y

Y

N

An outsider knowing the name of the system just dialed into

Y

Y

N

A user copying files of other users

Y

N

N

A user reading another user's electronic mail

Y

N

N

A user writing data into another user's file

Y

N

N

A user deleting another user's file

Y

N

N

A user being able to read sections of a disk that might contain various old files

Y

N

N

A user consuming machine time and resources to perform unrelated or unauthorized work, possibly even playing games

Y

N

N

If you can tolerate most of the events listed, your security requirements are quite low. If your answers are mixed, your requirements are in the medium to high range. Generally, those sites that are most intolerant to the listed events have very high levels of security requirements.

When you review your site's security needs, do not confuse a weakness in site operations or recovery procedures as a security problem. Ensure that your operations policies are effective and consistent before evaluating your system security requirements.

1.3. Building a Secure System Environment

There are two sources of security problems outside the operating system domain: employee carelessness and facility vulnerability. If you have a careless or malicious employee or your facility is insecure, none of the security measures discussed in this guide will protect you from security breaches.

Most system penetration occurs through these environmental weaknesses. It is much easier to physically remove a small reel of tape than it is to break access protection codes or change file protection.

VSI strongly encourages you to stress environmental considerations as well as operating system protection when reviewing site security.

This book discusses operating system security measures. When deciding which of these measures to implement, it is important for you to assess site security needs realistically. While instituting adequate security for your site is essential, instituting more security than actually necessary is costly and time-consuming.

When deciding which security measures to apply to your system, remember the following:
  • The most secure system is also the most difficult to use.

  • Increasing security can increase costs in terms of slower access to data, slower machine operations, and slower system performance.

  • More security measures require more personnel time.

The operating system provides the basic mechanisms to control access to the system and its data. It also provides monitoring tools to ensure that access is restricted to authorized users. However, many computer crimes are committed by authorized users with no violation of the operating system's security controls.

Therefore, the security of your operation depends on how you apply these security features and how you control your employees and your site. By first building appropriate supervisory controls into your application and designing your application with the goal of minimizing opportunities for abuse, you can then implement operating system and site security features and produce a less vulnerable environment. For an example of one organization's security plan, see Chapter 6.

1.4. Encryption

The OpenVMS operating system provides several data protection schemes. For example, by using UIC-based protection you can protect data by controlling access to files. You can use ACLs to refine access control to specific groups or individual users. For a protection scheme with yet greater security for your data, you can encrypt the files. Encrypting a file transforms it into unrecognizable, unintelligible data, even if someone manages to gain access to it.

1.4.1. Encryption Process

The process of encryption takes readable data, called plaintext, and uses a mathematical algorithm to transform the plaintext into an unreadable, unintelligible form, called ciphertext.

To encrypt the plaintext data, the encryption operation requires a key. The key is a variable that controls the encryption operation. The same plaintext, encrypted with different keys, results in different ciphertext. In addition, repeated encryption of the same plaintext with the same key also results in different ciphertext each time.

OpenVMS Version 8.3 integrates the former Encryption for OpenVMS software product into the operating system. This eliminates the need for a separate product installation and product license. In addition, OpenVMS Version 8.3 and later supports the Advanced Encryption Standard (AES) algorithm.

1.4.1.1. AES Encryption Algorithm

The AES algorithm allows OpenVMS users, system managers, security managers, or programmers to secure their files, save sets, or application data with AES encryption. DES and AES are similar encryption algorithms. They are both block cipher algorithms. However, encryption using AES algorithms is found to be more secure than DES encryption due to the number of rounds the plain text undergoes during its transformation to ciphered text. The number of rounds depend on the key size. For example, a key size of 128 bits invokes 10 rounds of transformation. Similarly, key sizes of 192 bits and 256 bits invoke 12 and 14 rounds, respectively. For more information on AES encryption algorithm, see Chapter 9

1.4.1.2. DES Encryption Algorithm

The algorithm used by OpenVMS is a software implementation of the Data Encryption Standard (DES) defined by the National Bureau of Standards (NBS). The NBS document FIPS-PUB-46 describes the operation of the DES algorithm in detail.

Because the DES algorithm is public knowledge, the security of your ciphertext files depends on the keys you define.

1.4.1.3. Keys

OpenVMS encryption uses two keys:

  • Key that you provide.

  • Key that the software randomly generates, called the data key.

The key you provide encrypts the data key, which is stored in the first block of the ciphertext file. The process uses the encrypted data key to encrypt the file. You have the option to encrypt either the data key or the file.

Table 1.2 shows the components of the encryption process.

Table 1.2. Components of the Encryption Operation
InputAlgorithmOutput
User-supplied data keyKey encryptionEncrypted key
Data (plaintext) and the encrypted data keyData encryptionEncrypted file

Figure 1.1 illustrates the data encryption operation. In this example, the input file contains the text "secret" and the key has been defined as "elmno jflghi." The output file is unreadable text.

Figure 1.1. Encrypting a File
Encrypting a File

1.4.1.4. Decryption

To gain access to the data in an encrypted file, reverse the encryption process by performing the decryption process. Decryption uses a mathematical encryption algorithm to change ciphertext into the original plaintext.

Before decrypting a file, the software checks the validity of the key you provide. This validation is a checksum operation on the encrypted data stored in the first block of the ciphertext file.

When you specify the AES/DES algorithm to decrypt a file, use the key that is identical to the one used in the original encryption process.

Note

Only the correct key can decrypt your file. If you lose or forget the key, you cannot gain access to the data in any understandable, useful form.

Figure 1.2 shows the data decryption operation. In this example, the input file holds unreadable text. The key, "elmno jflghi," is the same key that was used to encrypt this file. The output file contains the readable text "secret."

Figure 1.2. Decrypting a File
Decrypting a File

1.4.2. Authentication Process

OpenVMS detects any modification made to both plaintext and ciphertext files. This process is called authentication. Authentication checks for and reports on any changes to:

  • File data

  • File location

  • Authentication key

  • Security settings

The software calculates two Message Authentication Codes (MACs): one based on file contents and one based on security settings. The software then associates them with one or more files and stores this information. When you subsequently check file integrity, the software recalculates the MACs and compares them against the stored codes.

Note

Currently, MAC authentication is supported only with DES algorithm.

1.4.3. Encryption Interfaces

To define and delete keys, and to encrypt and decrypt files, use the following Encryption interfaces:

  • DCL commands – for interactive encryption functions. These commands encrypt files and backup save sets. For more information on using DCL commands, see Chapter 9.

  • Callable routines – for application programming. These routines encrypt files and small blocks. For more information, see the VSI OpenVMS Utility Routines Manual.

1.4.4. Compatibility

Encrypted files are fully compatible between OpenVMS systems. You can copy them from system to system and do all remote file operations that OpenVMS systems support for other kinds of files. In addition, you can encrypt files on one system and decrypt them on another system that also runs the Encryption software. Inter-system encryption operations with non-OpenVMS platforms are not supported.

1.5. Common Data Security Architecture (CDSA)

Common Data Security Architecture (CDSA) is deprecated. VSI provides CDSA as part of VSI OpenVMS Versions 8.4-2, 8.4-2L1, and 8.4-2L2 to allow old CDSA signed applications to be run on the system. CDSA will be removed in future VSI OpenVMS releases.

1.6. Secure Sockets Layer (SSL)

Secure Sockets Layer (SSL) is the open standard security protocol for the secure transfer of sensitive information over the Internet. SSL provides three things: privacy through encryption, server authentication, and message integrity. Client authentication is available as an optional function.

Starting with Version 7.3-1, SSL is provided as part of the OpenVMS Alpha operating system. SSL is compatible with OpenVMS Alpha Version 7.2-2 and higher, and OpenVMS VAX Version 7.3 and higher.

Protecting communication links to OpenVMS applications over a TCP/IP connection can be accomplished through the use of SSL. The OpenSSL APIs establish private, authenticated and reliable communications links between applications.

The SSL protocol works cooperatively on top of several other protocols. SSL works at the application level. The underlying mechanism is TCP/IP (Transmission Control Protocol/Internet Protocol), which governs the transport and routing of data over the Internet. Application protocols, such as HTTP (HyperText Transport Protocol), LDAP (Lightweight Directory Access Protocol), and IMAP (Internet Messaging Access Protocol), run on top of TCP/IP. They use TCP/IP to support typical application tasks, such as displaying web pages or running email servers.

SSL addresses three fundamental security concerns about communication over the Internet and other TCP/IP networks:

  • SSL server authentication—Allows a user to confirm a server's identity. SSL-enabled client software can use standard techniques of public-key cryptography to check whether a server's certificate and publicID are valid and have been issued by a Certificate Authority (CA) listed in the client's list of trusted CAs. Server authentication is used, for example, when a PC user is sending a credit card number to make a purchase on the web and wants to check the receiving server's identity.

  • SSL client authentication—Allows a server to confirm a user's identity. Using the same techniques as those used for server authentication, SSL-enabled server software can check whether a client's certificate and public ID are valid and have been issued by a Certificate Authority (CA) listed in the server's list of trusted CAs. Client authentication is used, for example, when a bank is sending confidential financial information to a customer and wants to check the recipient's identity.

  • An encrypted SSL connection—Requires all information sent between a client and a server to be encrypted by the sending software and decrypted by the receiving software, thereby providing a high degree of confidentiality. Confidentiality is important for both parties to any private transaction. In addition, all data sent over an encrypted SSL connection is protected with a mechanism that automatically detects whether data has been altered in transit.

For more information about SSL, see the HP Open Source Security for OpenVMS, Volume 2: HP SSL for OpenVMS .

1.7. Kerberos

Kerberos is a network authentication protocol developed by the Massachusetts Institute of Technology (MIT). The Kerberos protocol uses secret-key cryptography to provide strong authentication for client/server applications. Using Kerberos, a client can prove its identity to a server (and vice versa) across an insecure network connection. After a client and server have used Kerberos to prove their identity, they can also encrypt all of their communications to assure privacy and data integrity. For more information about MIT Kerberos, visit https://web.mit.edu/kerberos/.

Starting with OpenVMS Alpha Version 7.3-1 and OpenVMS Integrity Version 8.2, Kerberos is provided as part of the OpenVMS operating system. Kerberos is compatible with OpenVMS Alpha Version 7.2-2 and higher, and OpenVMS VAX Version 7.3 and higher.

Chapter 2. OpenVMS Security Model

This chapter presents the concepts that guided the design and implementation of the security features and mechanisms incorporated into the operating system. The intent is to provide a framework for thinking about your total system security picture. Subsequent chapters present details about the security features and their use.

2.1. Structure of a Secure Operating System

In the late 1960s, a great deal of research and development was dedicated to the problem of achieving security in multiuser computer systems. Much of the development work involved attempts to find all the things that could go wrong with a system's security and then to correct those flaws one by one. It became apparent to the researchers that this process was ineffective; effective system security could result only from a basic model of the structure of a secure computer system. The reference monitor concept was proposed as such a model and gained wide acceptance.

2.1.1. Reference Monitor Concept

According to the reference monitor concept, a computer system can be depicted in terms of subjects, objects, an authorization database, an audit trail, and a reference monitor, as shown in Figure 2.1. The reference monitor is the control center that authenticates subjects and implements and enforces the security policy for every access to an object by a subject.

Figure 2.1. Reference Monitor
Reference Monitor
The following table describes the elements shown in Figure 2.1:

Item

Element

Description

1

Subjects

Active entities, such as user processes, that gain access to information on behalf of people.

2

Objects

Passive repositories of information to be protected, such as files.

3

Authorization database

Repository for the security attributes of subjects and objects. From these attributes, the reference monitor determines what kind of access (if any) is authorized.

4

Audit trail

Record of all security-relevant events, such as access attempts, successful or not.

2.1.2. How the Reference Monitor Enforces Security Rules

The reference monitor enforces the security policy by authorizing the creation of subjects, by granting subjects access to objects based on the information in a dynamic authorization database, and by recording events, as necessary, in the audit trail. In an ideal system, the reference monitor must meet the following three requirements:
  • Mediate every attempt by a subject to gain access to an object

  • Provide a tamperproof database and audit trail that are thoroughly protected from unauthorized observation and modification

  • Remain a small, simple, and well-structured piece of software so that it is effective in enforcing security requirements

These are the requirements proposed for systems that are secure even against penetration. In such systems, the reference monitor is implemented by a security-related subset, or security kernel, of the operating system.

2.2. Implementation of the Reference Monitor

While the OpenVMS operating system does not implement the reference monitor as a security-related subset, or security kernel, its interface to users and system managers does mirror the basic structure dictated by the reference monitor concept. Experience shows that incorporating such a structure is the best way to build a system resistant to probing and to most attempts at penetration.

The following sections describe the OpenVMS operating system's implementation of the reference monitor model.

2.2.1. Subjects

Subjects are the users or user agents (the user processes) that access information and, in some cases, may be prevented from accessing information. Subjects can be interactive processes, network processes, or batch jobs, and:
  • Must pass security controls
    • During process creation
    • During information access
  • Require identification
    • User names
    • Passwords
    • User identification codes
    • Rights identifiers

When a user logs in to use the operating system interactively or when a batch or network job starts, the operating system creates a process that includes the identity of the user. That process gains access to information as the agent for the user, as described in Chapter 4.

Processes are vulnerable to security breaches while they are being created and while they are accessing information. The system manages process access to information by using its authorization data and internal mechanisms, such as hardware controls. Because process creation has many areas of security vulnerability, many operating security features concentrate on the area of process (or subject) creation.

When a user attempts to log in to a system, the user provides a user name (a name that will be given to the resulting process) and a password. The password serves as an authenticator that should be known only to the user and to the operating system.

Because a short or obvious password is likely to fail this requirement, the system incorporates many password protection mechanisms that can be invoked by the user or required by the security administrator (see Chapter 7). The operating system is also capable of limiting the number of attempts that an intruder can make to guess a password.

The file of users' passwords is part of the security database that must be protected from unauthorized observation and modification. The system meets this requirement by storing the passwords in a file protected from general access, the system user authorization file (SYSUAF.DAT). The system takes the additional precaution of storing passwords in an encoded form that is hard to use if stolen.

Once the operating system creates a process for a user, it assigns a user identification code or UIC from the user authorization record to that process. The UIC corresponds to the name of the user who created the process (as authenticated by the user's password). In addition, the UIC indicates the user's membership in a group that can correspond to the user's department, project, or function. The system can also attach additional information to the process regarding the creation of the process and the affiliation of the process owner with other groups. This additional information plays a part in the application of the authorization database. (Both Chapter 4 and Chapter 8 discuss UICs.)

2.2.2. Objects

In the reference monitor concept, objects are passive repositories of information. In the OpenVMS system, there are many objects, such as files and devices, that are subject to protection, as described in Table 2.1. The operating system protects objects from unauthorized access and provides a variety of mechanisms (described in Chapter 4 and Chapter 5) for sharing them in a controlled manner. These mechanisms are also used to control access to system resources.
Table 2.1. Objects Protected by Security Controls

Class Name

Definition

Capability

A resource to which the system controls access; currently, the only defined capability is the vector processor.

Common event flag cluster

A set of 32 event flags that enable cooperating processes to post event notifications to each other.

Device

A class of peripherals connected to a processor that are capable of receiving, storing, or transmitting data.

File

Files-11 On-Disk Structure Level 2 (ODS-2) files and directories.

Group global section

A shareable memory section potentially available to all processes in the same group.

Logical name table

A shareable table of logical names and their equivalence names for the system or a particular group.

Queue

A set of jobs to be processed in a batch, terminal, server, or print job queue.

Resource domain

A namespace controlling access to the lock manager's resources.

Security class

A data structure containing the elements and management routines for all members of the security class.

System global section

A shareable memory section potentially available to all processes in the system.

Volume

A mass storage medium, such as a disk or tape, that is in ODS-2 format. Volumes contain files and may be mounted on devices.

2.2.3. Authorization Database

According to the reference monitor model, each subject's authorization to gain access to an object is based on an abstract authorization database. This database is a set of dynamic security attributes that govern a subject's access to an object at any given time. In the OpenVMS system, the database is distributed and stored in association with the objects that must be protected. For example, the authorization data for a file or directory is stored in the file header for that file or directory. Table 2.2 summarizes the information stored in the authorization database.
Table 2.2. Information Stored in the Authorization Database

File

Contents

Data Used to Interpret

SYSUAF.DAT

User names

Logins

Passwords

Logins

UICs

Access control checks

NETPROXY.DAT

User names

Logins

NET$PROXY.DAT

User names

Logins

RIGHTSLIST.DAT

Rights identifiers

Access control checks

VMS$OBJECTS.DAT

UICs

Access control checks

Protection codes

Access control checks

Access control lists

Access control checks

VMS$AUDIT_SERVER.DAT

Auditable events

Reporting of events

As Section 2.2.2 suggests, different objects in the OpenVMS system can be shared with differing levels of flexibility. Protected objects are subject to a protection code. This code specifies whether access is allowed or denied to processes run on behalf of system users, the user who is owner of the object, other members of the UIC group of the owner, and all other users.

In addition to the protection code, objects can be shared under control of access control lists (ACLs). ACLs provide a finer granularity of access control than UIC-based protection, especially for user groups or subsets of groups. ACLs list individual users or groups of users who are to be allowed or denied particular types of access to the object. ACLs specify sharing on the basis of UIC identification as well as other groupings or identifiers that can be associated with a process. For example, it is possible to specify that a file should never be read by a process connected to a terminal on a dialup line. Section 2.2.6 uses an access matrix to explain the concept of an ACL. Section 4.4 gives a general discussion of ACLs and identifiers, and Chapter 8 explains how you, as security administrators, can create identifiers and construct ACLs for system resources.

2.2.4. Audit Trail

All security-relevant events can be recorded in an audit log file, sent to an operator terminal, or both. A terminal can be designated as a security operator terminal where all auditable events can be displayed. An audit log file provides a permanent record of security events. Many times a security administrator can find a pattern of activity, called an audit trail, by studying the log file.

The operating system audits the classes of security events shown in Table 2.3 by default. You can select other events for auditing, such as volume mounts or changes to system time.
Table 2.3. Security Auditing Overview

Destination

Events Audited by Default

Log file or terminal display

Authorization database changes

Intrusion attempts

Login failures

Use of DCL command SET AUDIT

Events triggered by Audit or Alarm ACEs

The audit log allows users and security administrators to record many events. Because it is time-consuming to examine every event, it is most efficient to audit events that will contribute the most information to your security picture. See Chapter 10 for a description of security auditing.

2.2.5. Reference Monitor

In the OpenVMS operating system, the executive performs the role of the reference monitor. All system programs that run in kernel and executive mode help implement the reference monitor, as do the command line interpreter and certain user-mode images that run with privilege. While the volume of code comprising the executive is large, VSI attempts to ensure that none of the code can be used to bypass system security.

Some privileges can grant a user the authority to modify or subvert the reference monitor. For example, a process with the CMKRNL privilege can execute code of its own within the system kernel, gaining access to the reference monitor's internal data and the internal representation of protected objects. Clearly, granting such critical privileges should be severely limited.

Similarly, give privileges such as SYSPRV and SECURITY only to users whose processes help maintain the reference monitor and authorization database.

2.2.6. Authorization Database Represented as an Access Matrix

The reference monitor model specifies an authorization database, which describes all access authorizations in the system for all subjects and all objects. This database is often represented as an access matrix, which lists subjects on one axis and objects on the other (see Figure 2.2). Each crosspoint in the matrix thus represents the access that one subject has to one object.

Figure 2.2. Authorization Access Matrix
Authorization Access Matrix

In this access matrix, an asterisk (*) denotes that the subject has access to that object. (Different types of access, such as read and write, are omitted from this example for simplicity.) Thus, subjects B, C, and D all have access to objects W, X, and Y. In addition, subject A has access to objects W and Z, subject D to object V, and subject E to object V.

Breaking up the access matrix by rows yields a capability-based model, in which each subject carries a list of the objects that it can access. Thus, a capability representation of this access matrix would appear as follows:

A: W, Z B: W, X, Y C: W, X, Y D: V, W, X, Y E: V

It is also possible to break up the access matrix by columns, listing for each object the subjects that have access to it. This results in an authority-based model, implemented in the OpenVMS system by ACLs (see Chapter 4). The ACL representation appears as follows:

V: D, E W: A, B, C, D X: B, C, D Y: B, C, D Z: A

The ACL and identifier controls used by the operating system combine the properties of both the capability- and authority-based systems. In OpenVMS systems, both subjects and objects carry identifiers. Subjects can access objects if they have matching identifiers and if the objects' access statements grant the requested access.

The result of combining properties of the capability- and authority-based systems is an extremely powerful and flexible system capable of representing complex access matrixes in a compact and convenient manner. Consider what happens to the previous example of an access matrix when some of the cross-points have labels, as shown in Figure 2.3.

Figure 2.3. Authorization Access Matrix with Labeled Cross-Points
Authorization Access Matrix with Labeled Cross-Points

Some labeled cross-points can be grouped and treated as a single entity. Thus, the points that are labeled Q in Figure 2.3 represent the access that subjects B, C, and D have to objects W, X, and Y. All the Q points can be considered as a single area of interest. The system provides the concept of identifiers to take practical advantage of this grouping of areas of interest.

You can define identifiers to represent the two groups of access, P and Q, in Figure 2.3. Note that two of the cross-points in the matrix remain unlabeled. Identifiers can also represent individual subjects and thus allow the traditional ACL facility.

To represent the access matrix, the OpenVMS operating system uses two structures, one for each dimension:
  • The rights list (RIGHTSLIST.DAT) represents the rows of the access matrix and thus corresponds to the capability-based model. For the matrix in Figure 2.3, you would need the following rights list:

    B: Q C: Q D: P, Q E: P

  • ACLs for the protected objects represent the columns of the access matrix. For this example, you would need the following ACLs:

    V: P W: A, Q X: Q Y: Q Z: A

Note that the system structures required to represent the access matrix are simpler than either the traditional capability- or authority-based model and require fewer terms in total. In the example, the difference is slight. However, complexity of the access matrix increases with the square of its size.

2.3. Summary: System Security Design

When designing an overall system security plan, ask yourself the following questions:
  • How are users associated with subjects? What is the reliability of the authentication mechanism?

  • What objects contain sensitive information in this system or application? Is access to those objects controlled?

  • Does the authorization database reflect the site's security policy? Who is authorized to gain access to sensitive objects? Are adequate restrictions in place?

  • Is the audit trail recording enough or too much information? Who will monitor it? How often will it be examined?

  • What programs are functioning as part of the reference monitor? Which users can modify the security policy and the authorization database? Is this the desired configuration?

These considerations, as well as the underlying reference monitor design, apply equally to a timesharing system, a widespread network, or a single application on a system that grants access to records in a file or database. The operating system provides general mechanisms that users and security administrators must apply to achieve system security. See Chapter 6 for more information on designing and implementing a security policy.

Chapter 3. Using the System Responsibly

This chapter provides basic information on how to use the system securely. If you apply this knowledge consistently and accurately, while observing your site's specific security policies, you can make the difference between a secure system and one that is vulnerable to unauthorized users.

3.1. Choosing a Password for Your Account

To choose a secure password, use the following guidelines:
  • Include both numbers and letters in the password. Although a 6-character password that contains only letters is secure, a 6-character password with both letters and numbers is much more secure.

  • Choose passwords that contain 6 to 10 characters. Adequate length makes passwords more secure. You can choose a password as long as 32 characters.

  • Do not select passwords from a dictionary or from your native language.

  • Avoid choosing words readily associated with your computer site or yourself, such as the name of a product or the model of your car.

  • Choose new passwords each time. Do not reuse old ones.

Your security administrator may set up additional restrictions, for example, not allowing passwords with fewer than 10 characters.

Table 3.1 provides examples of secure as opposed to risky passwords.
Table 3.1. Secure and Insecure Passwords

Secure Passwords

Insecure Passwords

Nonsense syllables: aladaskgam eojfuvcue joxtyois

Words with a strong personal association: your name the name of a loved one the name of your pet the name of your town the name of your automobile

A mixed string: 492_weid $924spa zu_$rags

A work-related term: your company name a special project your work group name

3.1.1. Obtaining Your Initial Password

Typically, when you learn that an account has been created for you on the system, you are told whether a user password is required. If user passwords are in effect, you are told to use a specific password for your first login. This password has been placed in the system user authorization file (SYSUAF.DAT) with other information about how your account can be used.

It is inadvisable to have passwords that can be easily guessed. Ask the person creating an account for you to specify a password that is difficult to guess. If you have no control over the password you are given, you might be given a password that is the same as your first name. If so, change it immediately after you log in. (The use of first or last names as passwords is a practice so well known that it is undesirable from a security standpoint.)

Log in to your account soon after it is created to change your password. If there is a time lapse from the moment when your account is created until your first login, other users might log in to your account successfully, gaining a chance to damage the system. Similarly, if you neglect to change the password or are unable to do so, the system remains vulnerable. Possible damage depends largely on what other security measures are in effect.

At the time your account is created, you should also be told a minimum length for your password and whether you can choose your new password or let the system generate the password for you.

3.1.2. Observing System Restrictions on Passwords

The system screens passwords for acceptability, as follows:
  • It automatically compares new passwords to a system dictionary. This helps to ensure that a password is not a native language word.

  • It maintains a history list of your old passwords and compares each new password to this list to be sure that you do not reuse an old password.

  • It enforces a minimum password length, which the system manager specifies in your UAF record.

3.2. Knowing What Type of Password to Use

There are several types of passwords recognized by the OpenVMS operating system. In general, you need to provide a user password when you log in. In some cases, you might also need to provide a system password to gain access to a particular terminal before logging in with your user password. If you are using a system with high security requirements, you might need to provide a primary password and a secondary password.

If you are an externally authenticated user with external authentication enabled on your system, you enter your LAN Manager password at the OpenVMS password prompt. See Section 7.4 for more information. Table 3.2 describes each type of password.
Table 3.2. Types of Passwords

Password

Description

User password

Required for most accounts. After you enter your user name, you are prompted for a password. If the account requires both primary and secondary passwords, you must enter two passwords.

System password

Controls access to particular terminals and is required at the discretion of the security administrator. System passwords are usually necessary to control access to terminals that might be targets for unauthorized use, such as dialup and public terminal lines.

Primary password

The first of two user passwords to be entered for an account requiring both primary and secondary passwords.

Secondary password

The second of two user passwords to be entered for an account requiring both primary and secondary passwords. The secondary password provides an additional level of security on user accounts. Typically, the general user does not know the secondary password; a supervisor or other key person must be present to supply it. For certain applications, the supervisor may also decide to remain present while the account is in use. Thus, secondary passwords facilitate controlled logins and the actions taken after a login.

Secondary passwords can be time-consuming and inconvenient. They are justified only at sites with maximum security requirements. An example of an account that justifies dual passwords would be one that bypasses normal access controls to permit emergency repair to a database.

3.2.1. Entering a System Password

Your security administrator will tell you if you must specify a system password to log in to one or more of the terminals designated for your use. Ask your security administrator for the current system password, how often it changes, and how to obtain the new system password when it does change.

To specify a system password, do the following:
  1. Press the Return key until the terminal responds with the recognition character, which is normally a bell.
    Return
    <bell>
  2. Enter the system password, and press Return.
    Return

    As this example shows, there is no prompt and no echo of the characters you type. If you fail to specify the correct system password, the system does not notify you. (Initially, you might think the system is malfunctioning unless you know that a system password is required at that terminal.) If you do not receive a response from the system, assume that you have entered the wrong password, and try again.

  3. When you enter the correct system password, you receive the system announcement message, if there is one, followed by the Username: prompt.

    For example:
    MAPLE - A member of the Forest Cluster
         Unauthorized Access Is Prohibited
    Username:

3.2.2. Entering a Secondary Password

Your security administrator decides whether to require the use of secondary passwords for your account at the time your account is created. When your account requires primary and secondary passwords, you need two passwords to log in. Minimum password length, which the security administrator specifies in your UAF record, applies to both passwords.

An example of a login requiring primary and secondary passwords follows:
     WILLOW - A member of the Forest Cluster
         Welcome to OpenVMS on node WILLOW
Username: RWOODS
Password:
Return
Password:
Return

Last interactive login on Friday, 12-DEC-2008 10:22
$

As with a single password login, the system allots a limited amount of time for the entire login. If you do not enter a secondary password in time, the login period expires.

3.3. Password Requirements for Different Types of Accounts

Five types of user accounts are available on OpenVMS systems:
  • Accounts secured with passwords that you or the security administrator change periodically. This account type is the most common.

  • Accounts secured with authentication cards that have your password programmed onto the device. Many third-party products support this type of authentication mechanism.

  • Accounts that always require passwords but prohibit you from changing the password. By locking the password (setting the LOCKPWD flag in the UAF record), the security administrator controls all changes made to the password.

  • Restricted accounts limit your use of the system and sometimes require a password.

  • Open accounts require no password; the password is null. When you log in to an open account, the system does not prompt you for a password, and you do not need to enter one. You can begin entering commands immediately. Because open accounts allow anyone to gain access to the system, they are used only at sites with minimal security requirements and should normally be set up as restricted accounts.

3.4. Types of Logins and Login Classes

Logins can be either interactive or noninteractive. When you log in interactively, you enter an OpenVMS user name and a password. In noninteractive logins, the system performs the identification and authentication for you; you are not prompted for a user name and password. (The term interactive, as used here, differs from an interactive mode process defined by the DCL lexical function F$MODE(). For a description of the F$MODE function, see the VSI OpenVMS DCL Dictionary.)

In addition to interactive and noninteractive logins, the OpenVMS operating system recognizes different classes of logins. How you log in to the system determines the login class to which you belong. Based on your login class, as well as the time of day or day of the week, the system manager controls your access to the system.

3.4.1. Logging In Interactively: Local, Dialup, and Remote Logins

Interactive logins include the following login classes:
  • Local

    You log in from a terminal connected directly to the central processor or from a terminal server that communicates directly with the central processor.

  • Dialup

    You log in to a terminal that uses a modem and a telephone line to make a connection to the computer system. Depending on the terminal that your system uses, you might need to execute a few additional steps. Your site security administrator can give you the necessary details.

  • Remote

    You log in to a node over the network by entering the DCL command SET HOST. For example, to access the remote node HUBBUB, you enter the following command:
    $ SET HOST HUBBUB

    If you have access to an account on node HUBBUB, you can log in to that account from your local node. You have access to the facilities on node HUBBUB, but you remain physically connected to your local node.

3.4.2. Logging In Using External Authentication

If you are an externally authenticated user, you log in by entering your LAN Manager user ID and password at the OpenVMS login prompts. Your LAN Manager user ID may or may not be the same as your OpenVMS user name.

See Section 7.4 for more information on logging in with external authentication enabled on your system.

3.4.3. Reading Informational Messages

When you log in from a terminal that is directly connected to a computer, the OpenVMS system displays informational system messages. Example 3.1 illustrates most of these messages.
Example 3.1. Local Login Messages
WILLOW - A member of the Forest Cluster                      1
Unlawful Access is Prohibited
Username:  RWOODS
Password:
  You have the following disconnected process:               2
Terminal   Process name    Image name
VTA52:     RWOODS          (none)
Connect to above listed process [YES]:
NO
           Welcome to OpenVMS on node WILLOW                 3
    Last interactive login on Wednesday,  3-DEC-2008 10:20   4
    Last non-interactive login on Monday, 3-DEC-2008 17:39   5
         2 failures since last successful login              6
           You have 1 new mail message.                      7
$

1

The announcement message identifies the node (and, if relevant, the cluster). It may also warn unauthorized users that unlawful access is prohibited. The system manager or security administrator can control both the appearance and the content of this message.

2

A disconnected job message informs you that your process was disconnected at some time after your last successful login but is still available. You have the option of reconnecting to the old process and returning your process to its state before you were disconnected.

The system displays the disconnected job message only when the following conditions exist:
  • The terminal where the interruption occurred is set up as a virtual terminal.

  • Your terminal is set up as one that can be disconnected.

  • During a recent session, your connection to the central processing unit (CPU) through that terminal was broken before you logged out.

In general, the security administrator should allow you to reconnect to a disconnected job because this ability poses no special problems for system security. However, the security administrator can disable this function by changing the setup on terminals and by disabling virtual terminals on the system.

3

A welcome message indicates the version number of the OpenVMS operating system that is running and the name of the node on which you are logged in. The system manager can choose a different message or can suppress the message entirely.

4

The last successful interactive login message provides the time of the last completed login for a local, dialup, or remote login. (The system does not count logins from a subprocess whose parent was one of these types.)

5

The last successful noninteractive login message provides the time the last noninteractive (batch or network) login finished.

6

The number of login failures message indicates the number of failed attempts at login. (An incorrect password is the only source of login failure that is counted.) To attract your attention, a bell rings after the message appears.

7

The new mail message indicates if you have any new mail messages.

A security administrator can suppress the announcement and welcome messages, which include node names and operating system identification. Because login procedures differ from system to system, it is more difficult to log in without this information.

The last login success and failure messages are optional. Your security administrator can enable or disable them as a group. Sites with medium-level or high-level security needs display these messages because they can indicate break-in attempts. In addition, by showing that the system is monitoring logins, these messages can be a deterrent to potential illegal users.

Each time you log in, the system resets the values for the last successful login and the number of login failures. If you access your account interactively and do not specify an incorrect password in your login attempts, you may not see the last successful noninteractive login and login failure messages.

3.4.4. When the System Logs In for You: Network and Batch Logins

Noninteractive logins include network logins and batch logins.

The system performs a network login when you start a network task on a remote node, such as displaying the contents of a directory or copying files stored in a directory on another node. Both your current system and the remote system must be nodes in the same network. In the file specification, you identify the target node and provide an access control string, which includes your user name and password for the remote node.

For example, a network login occurs when user Greg, who has an account on remote node PARIS, enters the following command:
$ DIRECTORY PARIS"GREG 8G4FR93A"::WORK2:[PUBLIC]*.*;*

This command displays a listing of all the files in the public directory on disk WORK2. It also reveals the password 8G4FR93A. A more secure way to perform the same task would be to use a proxy account on node PARIS. For an example of a proxy login, see Section 3.9.2.

The system performs a batch login when a batch job that you submitted runs. Authorization to build the job is determined at the time the job is submitted. When the system prepares to execute the job, the job controller creates a noninteractive process that logs in to your account. No password is required when the job logs in.

3.5. Login Failures: When You Are Unable to Log In

Logins can fail for any number of reasons. One of your passwords might have changed, or your account might have expired. You might be attempting to log in over the network or from a modem but be unauthorized to do so. Table 3.3 summarizes common reasons for login failure.
Table 3.3. Reasons for Login Failure

Failure Indicator

Reason

No response from the terminal.

A defective terminal, a terminal that requires a system password, a terminal that is not powered on, or a communications problem caused by defective wiring or by a misconfigured or malfunctioning modem.

No response from any terminal.

The system is down or overloaded.

No response from the terminal when you enter the system password.

The system password changed.

System messages:

User authorization failure

A typing error in your user name or password.

The account or password expired.

Not authorized to log in from this source

Your particular class of login (local, dialup, remote, interactive, batch, or network) is prohibited.

Not authorized to log in at this time

You do not have access to log in during this hour or this day of the week.

User authorization failure (and no known user failure occurred)

An apparent break-in has been attempted at the terminal using your user name, and the system has temporarily disabled all logins at that terminal by your user name.

The following sections describe the reasons for login failure in more detail.

3.5.1. Using a Terminal That Requires a System Password

You cannot log in if the terminal you attempt to use requires a system password and you are unaware of the requirement. All attempts at logging in fail until you enter the system password.

If you know the system password, perform the steps described in Section 3.2.1. If your attempts fail, it is possible that the system password has been changed. Move to a different terminal that does not require a system password, or request the new system password.

If you do not know the system password and you suspect that this is the problem, try logging in at another terminal.

3.5.2. Observing Your Login Class Restrictions

If you attempt a class of login that is prohibited in your UAF record, your login fails. For example, your security administrator can restrict you from logging in over the network. If you attempt a network login, you receive a message stating that you are not authorized to log in from this source.

Network jobs are not terminated when the allocated work shift for network jobs is exceeded. This restriction applies only to new network connections, not to existing ones.

Your security administrator can restrict your logins to include or exclude any of the following classes: local, remote, dialup, batch, or network. (For a description of these classes, see Section 3.4.1 and Section 3.4.4.)

3.5.3. Using an Account Restricted to Certain Days and Times

Another cause of login difficulty is failure to observe your shift restrictions. A system manager or security administrator can control access to the system based on the time of day or the day of the week. These restrictions are imposed on classes of logins. The security administrator can apply the same work-time restrictions to all classes of logins or choose to place different restrictions on different login classes. If you attempt a login during a time prohibited for that login class, your login fails. The system notifies you that you are not authorized to log in at this time.

When shift restrictions apply to batch jobs, jobs you submit that are scheduled to run outside your permitted work times are not run. The system does not automatically resubmit such jobs during your next available permitted work time. Similarly, if you have initiated any kind of job and attempt to run it beyond your permitted time periods, the job controller aborts the uncompleted job when the end of your allocated work shift is reached. This job termination behavior applies to all jobs.

3.5.4. Failing to Enter the Correct Password During a Dialup Login

Your security administrator can control the number of chances you are given to enter a correct password during a dialup login before the connection is automatically broken.

If your login fails and you have attempts remaining, press the Return key and try again. You can do this until you succeed or reach the limit. If the connection is lost, you can redial the access line and start again.

The typical reason for limiting the number of dialup login failures is to discourage unauthorized users attempting to learn passwords by trial and error. They already have the advantage of anonymity because of the dialup line. Of course, limiting the number of tries for each dialup does not necessarily stop this kind of intrusion. It only requires the would-be perpetrator to redial and start another login.

3.5.5. Knowing When Break-In Evasion Procedures Are in Effect

If anyone has made a number of failed attempts to log in at the same terminal with your user name, the system concludes that an intruder is attempting to gain illegal access to the system by using your user name.

At the discretion of your security administrator, break-in evasion measures can be in effect for all users of the system. The security administrator controls how many password attempts are allowed over what period of time. Once break-in evasion tactics are triggered, you cannot log in to the terminal—even with your correct password—during a defined interval. Your security administrator can tell you how long you must wait before reattempting the login, or you can move to another terminal to attempt a login.

If you suspect that break-in evasion is preventing your login and you have not personally experienced any login failures, you should contact your security administrator immediately. Together, you should attempt another login and check the message that reveals the number of login failures since the last login to confirm or deny your suspicion of intrusion attempts. (If your system does not normally display the login message, your security administrator can use the Authorize utility (AUTHORIZE) to examine the data in your UAF record.) With prompt action, your security administrator can locate someone attempting logins at another terminal.

3.6. Changing Your Password

Changing passwords on a regular basis promotes system security. To change your password, enter the DCL command SET PASSWORD.

The system manager can allow you to select a password on your own or can require that you use the automatic password generator when you change your password. If you select your own password, note that the password must follow system restrictions on length and acceptability (see Section 3.1.2). For example, if your password choice is too short, the system displays the following message:
%SET-E-INVPWDLEN, invalid password length - password not changed

Section 3.1 provides guidelines and examples for specifying secure passwords.

There is no restriction on how many times you can change your password in a given period of time.

3.6.1. Selecting Your Own Password

If your system manager does not require use of the automatic password generator, the SET PASSWORD command prompts you to enter the new password. It then prompts you to reenter the new password for verification, as follows:
$ SET PASSWORD
Return
New password:
Verification:

If you fail to enter the same password twice, the password is not changed. If you succeed in these two steps, there is no notification. The command changes your password and returns you to the DCL prompt.

Even though your security administrator may not require the password generator, you are strongly encouraged to use it to promote the security of your system. Section 3.6.2 describes how to use generated passwords.

3.6.2. Using Generated Passwords

If your system security administrator decides that you must let the system generate the password for you automatically, the system provides you with a list of password choices when you enter the DCL command SET PASSWORD. (When the system does not require generated passwords, add the /GENERATE qualifier to SET PASSWORD for a list of password choices.) The character sequence resembles native language words to make it easy to remember, but it is unusual enough to be difficult for outsiders to guess. Because system-generated passwords vary in length, they become even more difficult to guess.

Note

The password generator uses basic syllabic rules to generate words but has no real knowledge of any language. As a result, it can unintentionally produce words that are offensive.

In the following OpenVMS VAX example, the system automatically generates a list of passwords made up of random sequences of characters. The minimum password length for the user in the following example has been set to 8 in the UAF record.
$ SET PASSWORD
Old password:
Return                     1
reankuna      rean-ku-na   2
cigtawdpau    cig-tawd-pau
adehecun      a-de-he-cun
ceebatorai    cee-ba-to-rai
arhoajabad    ar-hoa-ja-bad
Choose a password from this list, or press Return to get a new list 3
New password:
Return   4
Verification:
Return   5
$ 6
The preceding example illustrates the following:

1

The user correctly specifies the old password and presses the Return key.

2

The system responds with a list of five password choices ranging in length from 8 to 10 characters. There are representations of the same word divided into syllables to the right of each password choice. Usually the password that is easiest to pronounce is easiest to remember and, therefore, the best choice.

3

The system informs the user that it is possible to request a new list by pressing the Return key in response to the prompt for a new password.

4

The user enters one of the first five possible passwords and presses the Return key.

5

The system recognizes that this password is one provided by the automatic password generator and responds with the verification prompt. The user enters the new password again and presses Return.

6

The system changes the password and responds with the DCL prompt.

One disadvantage of automatic password generation is the possibility that you might not remember your password choice. However, if you dislike all the password choices in your list or think none are easy to remember, you can always request another list.

A more serious drawback of automatic password generation is the potential disclosure of password choices from the display the command produces. To protect your account, change your password in private. If you perform the change on a video terminal, clear the display of password choices from the screen after the command finishes. If you perform the change in a DECwindows environment, use the Clear Lines Off Top option from the Commands menu to remove the passwords from the screen recall buffer. If you use a printing terminal, properly dispose of all hardcopy output.

If you later realize that you failed to protect your password in these ways, change your password immediately. Depending on site policy or your own judgment concerning the length of time your account was exposed, you might decide to notify your security administrator that a security breach could have occurred through your account.

3.6.3. Changing a Secondary Password

To change a secondary password, use the DCL command SET PASSWORD/SECONDARY. You are prompted to specify the old secondary password and the new secondary password, just as in the procedure for changing the primary password. To remove a secondary password, press the Return key when you are prompted for a new password and verification.

You can change primary and secondary passwords independently, but both are subject to the same change frequency because they share the same password lifetime. See Section 3.7 for information on password lifetimes.

3.6.4. Changing Your Password As You Log In

Even if your current password has not yet expired, you can change your password when you log in to the system by including the /NEW_PASSWORD qualifier with your user name, as follows:
  WILLOW - A member of the Forest Cluster

Username: RWOODS/NEW_PASSWORD
Password:
         Welcome to OpenVMS on node WILLOW
         Last interactive login on Tuesday, 4-NOV-2008 10:20
         Last non-interactive login on Monday, 3-NOV-2008 14:20

Your password has expired; you must set a new password to log in
New password:
Verification:

Entering the /NEW_PASSWORD qualifier after your user name forces you to set a new password immediately after login.

3.7. Password and Account Expiration Times

Your system manager can set up your account so that your password, or the account itself, expires automatically on a particular date and time. Password expiration times promote system security by forcing you to change your password on a regular basis. Account expiration times help to ensure that accounts are available only for as long as they are needed.

3.7.1. Changing an Expired Password

As you approach the expiration time of your password, you receive an advance warning message. The message first appears 5 days before the expiration date and at each subsequent login. The message appears immediately below the new mail message and sounds the bell character on your terminal to attract your attention. The message indicates that your password is expiring, as follows:
WARNING – Your password expires on Thursday 18-DEC-2008 15:00
If you fail to change your password before it expires, you receive the following message when you log in:
Your password has expired; you must set a new password to log in
New password:

The system prompts you for a new password or, if automatic password generation is enabled, asks you to select a new password from those listed (see Section 3.6.2). You can abort the login by pressing Ctrl/Y. At your next login attempt, the system again prompts you to change your password.

When You Are Using a Secondary Password

If secondary passwords are in effect for your account (see Section 3.2), the secondary password may expire at the same time as the primary one. You are prompted to change both passwords. If you change the primary password and press Ctrl/Y before changing the secondary password, the login fails. The system does not record a password change.

When You Fail to Change Your Password

If the system manager decides not to force you to change your expired password upon logging in, you receive one final warning when you log in after your password expires, as follows:
WARNING – Your password has expired; update immediately with
SET PASSWORD!

At this point, if you do not change the password or if the system fails before you have the opportunity to do so, you will be unable to log in again. To regain access, see your system manager.

3.7.2. Renewing an Expired Account

If you need your account for a specific purpose for a limited time only, the person who creates your account may specify a period of time after which the account lapses. For example, student accounts at universities are typically authorized for a single semester at a time.

The system automatically denies access to expired accounts. You receive no advance warning message before the account expiration date, so it is important to know in advance your account duration. The account expiration resides in the UAF record, which can be accessed and displayed only through the use of the Authorize utility (AUTHORIZE) by users with the SYSPRV privilege or equivalent—normally, your system manager or security administrator.

When your account expires, you receive an authorization failure message at your next attempted login. If you need an extension, follow the procedures defined at your site.

3.8. Guidelines for Protecting Your Password

Illegal system access through the use of a known password is most often caused by the owner's disclosing the password. It is vital that you do not reveal your password to anyone.

You can best protect your password by observing the following rules:
  • Select reasonably long passwords that cannot be guessed easily. Avoid using words in your native language that appear in a dictionary. Consider including numbers in your password. Alternatively, let the system generate passwords for you automatically.

  • Never write down your password.

  • Never give your password to another user. If another user obtains your password, change it immediately.

  • Do not include your password in any file, including the body of an electronic mail message. (If anyone else reveals a password to you, delete the information promptly.)

    The character strings that appear with your actual password can make it easy for someone to find your password in a file. For example, a quotation mark followed by two colons ("::) always comes after a user name and password in an access control string. Someone attempting to break into the system could obtain your password by searching inadequately protected files for this string. Another way in which you might reveal your password is by using the word password in a text file, for example:
    My password is GOBBLEDYGOOK.
  • If you submit a batch job on cards, do not leave your password card where others may be able to obtain your password from it.

  • Do not use the same password for accounts on different systems.

    An unauthorized user can try one password on every system where you have an account. The account that first reveals the password might hold little information of interest, but another account might yield more information or more privileges, ultimately leading to a far greater security breach

  • Before you log in to a terminal that is already on, invoke the secure terminal server feature (if enabled) by pressing the Break key. The secure server ensures that the OpenVMS login program is the only program able to receive your login and thereby eliminates the possibility of revealing a password to a password grabber program. This is particularly relevant when you are working in a public terminal room.

    A password grabber program is a special program that displays an empty video screen, a screen that appears to show the system has just been initialized after a crash, or a screen that shows a nonexistent logout. When you attempt to log in, the program runs through the normal login sequence so you think you are entering your user name and password in a normal manner. However, once the program receives this key information and passes it on to the perpetrator, it displays a login failure. You might think you mistyped your password and be unaware that you have just revealed it to someone else.

  • Unless you share your password, change it every 3 to 6 months. VSI warns against sharing passwords. If you do share your password, change it every month.

  • Change your password immediately if you have any reason to suspect it might have been discovered. Report such incidents to your security administrator.

  • Do not leave your terminal unattended after you log in.

    You might think the system failed and came back up again, when actually someone has loaded a password-stealing program. Even a terminal that displays an apparently valid logout message might not reflect a normally logged out process.

  • Routinely check your last login messages. A password-stealing program cannot actually increase the login failure count, although it looks like a login failure to you. Be alert for login failure counts that do not appear after you log in incorrectly or that are one less than the number you experienced. If you observe this or any other abnormal failure during a login, change your password immediately, and notify your security administrator.

3.9. Network Security Considerations

This section describes how to use access control strings in file specifications and how to use proxy logins to help make network access more secure.

3.9.1. Protecting Information in Access Control Strings

Network access control strings can be included in the file specifications of DCL commands working across the DECnet for OpenVMS network. They permit a user on a local node to access a file on a remote node.

An access control string consists of the user name for the remote account and the user's password enclosed within quotation marks, as follows:
NODE"username password"::disk:[directory]file.type
Because access control strings include sufficient information to allow someone to break in to the remote account, they create serious security exposure. To protect access control string information, do the following:
  • Avoid revealing the information on either hardcopy or video terminals. If you use a hardcopy terminal, dispose of the output properly. If you use a video terminal, clear the screen, and empty the recall buffer with the DCL command RECALL/ERASE when the network job is completed. This prevents another user from seeing the password, either by displaying the command line with the Ctrl/B key sequence or with the DCL command RECALL/ALL. DECwindows users can clear the screen with the Clear Lines Off Top option from the Commands menu. Otherwise, a DECwindows user could use the scroll bar to view previously entered text.

  • Do not place networking commands that include access control strings in command procedures where they would be likely targets for discovery.

  • If you must put access control strings in your command procedures, provide these files with optimum file protection by using the techniques described in Chapter 4.

  • The use of access control strings in not permitted in an evaluated configuration. Please see your system administrator to determine if your system is running in an evaluated configuration.

To avoid the need for access control strings, you might prefer to use proxy login accounts, which are described in Section 3.9.2.

3.9.2. Using Proxy Login Accounts to Protect Passwords

Proxy logins let you access files across a network without specifying a user name or password in an access control string. Thus, proxy logins have the following security benefits:
  • Passwords are not echoed on the terminal where the request originates.

  • Passwords are not passed between systems where they might be intercepted in unencrypted form.

  • Passwords are not needed in command files to perform the remote access steps.

Before you can initiate a proxy login, the system or security administrator at the remote node must create a proxy account for you. Proxy accounts, like regular accounts, are created with the Authorize utility (AUTHORIZE). They are usually nonprivileged accounts. Security administrators can allow you access to one default proxy account and up to 15 other proxy accounts. While proxy logins require more setup effort on the part of system managers, they provide more secure network access and eliminate the need for users to enter access control strings.

The following examples illustrate the differences between a normal network login request and a proxy login request. For each example, the following conditions exist:
  • The user KMAHOGANY has two user accounts:
    • An account on node BIRCH with the password XYZ123ABC

    • An account on node WALNUT with the password A25D3255

  • KMAHOGANY has logged in to node BIRCH.

  • KMAHOGANY wants to copy the file BIONEWS.MEM from the default device and directory of the account on the node WALNUT.

The following diagram illustrates these conditions:

Figure 3.1. Network and Proxy Logins
Network and Proxy Logins
The user KMAHOGANY could use an access control string to copy the file BIONEWS.MEM, as follows:
$ COPY WALNUT"KMAHOGANY A25D3255"::BIONEWS.MEM  BIONEWS.MEM
Notice that the password A25D3255 echoes. Anyone who observes the screen can see it. In contrast, if KMAHOGANY has proxy access from node BIRCH to the account on node WALNUT, the command for copying the file BIONEWS.MEM is as follows:
$ COPY WALNUT::BIONEWS.MEM   BIONEWS.MEM

KMAHOGANY does not need to specify a password in an access control string. Instead, the system performs a proxy login from the account on node BIRCH into the account on node WALNUT. There is no exchange of passwords.

Using a General Access Proxy Account

Your security administrator can also authorize groups of users from foreign nodes to share in the use of a general access proxy account. For example, the security administrator at node WALNUT can create a general access account with the following conditions:
  • The user name GENACCESS.

  • Access limited to network logins.

  • A password known only to the owner of the account. (None of the remote users need to know it.) This helps to protect the account.

  • The default device and directory STAFFDEV:[BIOSTAFF].

If the security administrator grants BIRCH::KMAHOGANY proxy access to the GENACCESS account, the user KMAHOGANY can copy the file BIONEWS.MEM by entering the following command:
$ COPY WALNUT::[KMAHOGANY]BIONEWS.MEM   BIONEWS.MEM

Note that KMAHOGANY must specify the directory [KMAHOGANY] because the file BIONEWS.MEM is not in the default device and directory for the GENACCESS account (STAFFDEV:[BIOSTAFF]). In addition, the protection for the file BIONEWS.MEM must permit access to the GENACCESS account. Otherwise, the command fails.

When You Need to Specify the Name of a Proxy Account

If you have access to more than one proxy account on a given node and you do not want to use the default proxy account, specify the name of the proxy account. For example, to use a proxy account called PROXY2 instead of the GENACCESS account (the default), KMAHOGANY enters the following command:
$ COPY WALNUT"PROXY2"::[KMAHOGANY]BIONEWS.MEM BIONEWS.MEM

This command uses the PROXY2 account to copy the file BIONEWS.MEM from the [KMAHOGANY] directory on node WALNUT.

3.10. Auditing Access to Your Account and Files

Although it is the security administrator's job to monitor the system for possible intrusions, you can help the security administrator to audit access to your account and files.

This section describes how to monitor your last login time for possible intrusions. It also describes how to work with your security administrator to enable certain types of auditing.

3.10.1. Observing Your Last Login Time

The operating system maintains information in your UAF record about the last time you logged in to your account. Your security administrator decides whether the system should display this information at login time. Sites with medium to high security requirements frequently display this information and ask users to check it for unusual or unexplained successful logins and unexplained failed logins.

If there is a report of an interactive or a noninteractive login at a time when you were not logged in, report it promptly to your security administrator. Also change your password. The security administrator can investigate further by using accounting files and audit logs.

If you receive a login failure message and cannot account for the failure, it is likely that someone has been trying to access your account unsuccessfully. Check your password to ensure that it adheres to all recommendations for password security described in Section 3.8. If not, change your password immediately.

If you expect to see a login failure message and it does not appear or if the count of failures is too low, change your password. Report either of these indications of login failure problems to your security administrator.

3.10.2. Adding Access Control Entries to Sensitive Files

If you have key files that may have been accessed improperly, you may want to develop a strategy with your security administrator to audit access to the files.

Once you review the situation and ensure that you have done everything possible to protect your files with standard protection codes and general ACLs (described in Chapter 4), you may conclude that security auditing is required.

To specify security auditing, you can add special access control entries (ACEs) to files you own or to which you have control access. Keep in mind, however, that the audit log file is a systemwide mechanism, so VSI recommends that a site security administrator control the use of file auditing. Although you can add auditing ACEs to files over which you have control, the security administrator has to enable auditing of files on a system level.

For example, if user RWOODS and his security administrator agree that they must know when a highly confidential file, CONFIDREVIEW.MEM, is being accessed, RWOODS can add an entry to the existing ACL for the file CONFIDREVIEW.MEM, as follows:
$ SET SECURITY/ACL=(AUDIT=SECURITY,ACCESS=READ+WRITE-
_$ +DELETE+CONTROL+FAILURE+SUCCESS) CONFIDREVIEW.MEM 

After RWOODS adds the security-auditing entry, the security administrator enables file-access auditing so that access attempts are recorded. See Section 3.10.3.1 for more information on file-access auditing.

An access violation of one file frequently indicates access problems with other files. Therefore, the security administrator may need to monitor access to all key files having security-auditing ACEs. When undesired access is gained to key files, the security administrator must take immediate action.

3.10.3. Asking Your Security Administrator to Enable Auditing

A security administrator can direct the operating system to send an audit message to the system security audit log file or an alarm to terminals enabled as security operator terminals whenever security-relevant events occur. For example, the security administrator might identify one or more files for which write access is prohibited. An audit message can be sent to indicate attempted access to these files.

3.10.3.1. Auditing File Access

If you suspect intrusion attempts to your account, the security administrator may temporarily enable auditing for all file access. The security administrator can also enable auditing to monitor read access to your files to catch file browsers.

For example, assume you decide to audit the file CONFIDREVIEW.MEM, which has a security-auditing ACE (see Section 3.10.2). If user ABADGUY accesses CONFIDREVIEW.MEM and has delete access, the following audit record is written to the system security audit log file:
%%%%%%%%%%%  OPCOM  6-DEC-2008 07:21:11.10  %%%%%%%%%%%
Message from user AUDIT$SERVER on BOSTON
Security audit (SECURITY) on BOSTON, system id: 19424
Auditable event:        Attempted file access
Event time:             6-DEC-2008 07:21:10.84
PID:                    23E00231
Username:               ABADGUY
Image name:             BOSTON$DUA0:[SYS0.SYSCOMMON.][SYSEXE]DELETE.EXE
Object name:            _BOSTON$DUA1:[RWOODS]CONFIDREVIEW.MEM;1
Object type:            file
Access requested:       DELETE
Status:                 %SYSTEM-S-NORMAL, normal successful completion
Privileges used:        SYSPRV

The auditing message reveals the name of the perpetrator, the method of access (successful deletion accomplished by using the program [SYSEXE]DELETE.EXE), time of access (7:21 a.m.), and the use of a privilege (SYSPRV) to gain access to the file. With this information, the security administrator can take action.

Note that the security audit message is written to the security audit log file every time any file is accessed and meets the conditions specified in the audit entry of the ACL for that file (see Section 3.10.2). Access to the file CONFIDREVIEW.MEM, as well as access to any file on the system that is protected with security auditing, prompts an audit record to be written to the security audit log file.

After auditing has been introduced, check with your security administrator periodically to see if any additional intrusions have occurred.

3.10.3.2. Additional Events to Audit

In addition to file auditing, the security administrator can select other types of events that warrant special attention when they occur. Events triggering an audit or alarm may include the following:

Events Initiating Security Audits or Alarms

Logins, logouts, login failures, and break-in attempts

Volume mounts and dismounts

Modifications to:
  • System and user passwords
  • System time
  • System authorization file
  • Network proxy file
  • Rights database
  • SYSGEN parameters

Connection or termination of logical links

Execution of:
  • SET AUDIT command
  • NCP commands

Creation and deletion of selected protected objects

Installation of images

Selected types of access and deaccess to selected protected objects

Access event requested by an ACL on a protected object

Successful or unsuccessful use of a privilege or an identifier

Use of the process control system services, including $CREPRC and $DELPRC

3.11. Logging Out Without Compromising System Security

Logging out of a session conserves system resources and protects your files. Leaving a terminal on line represents one of the greatest sources of inside intrusions. When you leave your terminal on line and your office open, you have effectively given away your password and your privileges and have left your files and those of the other members of your group unprotected. Any user can easily and quickly transfer all files accessible through your account. A malicious insider could rename and delete your files and any other files to which you have write access. If you have special privileges, especially privileges in the Files or All category, a malicious user can do major damage.

Log out when you leave your office even for a brief period of time. If you have performed remote logins, you must log out of each node. The following sections describe security considerations for logging out of specific types of terminals or sessions.

3.11.1. Clearing Your Terminal Screen

You may want to clear your screen each time you log out from a terminal to ensure that your user name, node name, and operating system are not revealed to anyone else. If you are logging out after a remote login, the name of the node to which you return (the local node) is also revealed. If you access multiple accounts remotely (over the network), the final sequence of logout commands reveals all the nodes and user names that are accessible to you on each node (excluding the name of the furthest node reached). To those who can recognize the operating system from the prompt or a logout message, these displays also reveal the operating system.

At some sites, it may be important to leave nothing but the logout message on your screen, as follows:
  • If you are using a VT200- or later series terminal, you can clear the screen by pressing the Set-Up key and selecting the item from the resulting menu that corresponds to the DECwindows Clear Display menu option on the Commands menu.

  • If you are using a VT100-series terminal, press the Set-Up key. Then press the key marked for reset (the 0 key) followed by the Return key.

    Alternatively, to preserve temporary parameters, press the Set-Up key, and then press the key marked 80/132 columns (the 9 key) twice.

After the screen clears, the cursor is positioned at the top of the screen, next to the DCL prompt. Enter the DCL command LOGOUT at the prompt. The only information remaining after you log out is your logout command and the logout completion message, for example:
$ LOGOUT
RDOGWOOD     logged out at 14-AUG-2008 19:39:01.43

3.11.2. Disposing of Hardcopy Output

After you log out from a hardcopy terminal, properly remove, file, or dispose of all hardcopy output that might reveal sensitive information. Your security administrator should provide direction on preferred procedures. Many sites use paper shredders or locked receptacles for this purpose. Handle output that you plan to save just as carefully.

You should also dispose of hardcopy output if the system fails before you log out. In addition, if you will not be present when the system is initialized, turn your terminal off.

3.11.3. Removing Disconnected Processes

The system automatically removes your disconnected processes after a certain interval. You can conserve system resources, however, if you directly log out of any disconnected processes, as follows:
  1. Enter the DCL command SHOW USERS to determine if you have other disconnected jobs.

  2. Enter the DCL command CONNECT/LOGOUT to log out of the current process. Connect back through each of the associated virtual terminals (as noted by the terminal prefix of VTA) until you reach the last existing process.

  3. Enter the DCL command LOGOUT.

3.11.4. Breaking the Connection to a Dialup Line

Your security administrator may ask you to break the connection to a dialup line when you log out. If you anticipate no further immediate use of the line, use the LOGOUT command with the /HANGUP qualifier. The /HANGUP qualifier directs the system to automatically break the connection to the dialup line after you log out.

Note

The effectiveness of the /HANGUP qualifier depends on how your system manager configures your modem line and how the line connects to the computer. It does not work on lines connected to a terminal server.

Breaking the connection to a dialup line prevents someone from taking advantage of an open access line. To access the line, someone must know the access number and must personally redial. Breaking the connection is especially important if the dialup line you use is in a public area or where someone might use the terminal after you.

This practice also saves resources by reducing the required number of dialup lines.

3.11.5. Turning Off a Terminal

If your site has moderate or high security requirements, your security administrator may ask you to turn off your terminal after logging out. This resets terminal characteristics and clears memory buffers. Some Trojan horse attacks use hardware frame buffers and the answerback capabilities that are built into newer terminals.

3.12. Checklist for Contributing to System Security

Although security features are implemented by the security administrator as requirements for all users, this chapter has described ways in which you can contribute to system security. The following list reviews voluntary security actions:
  • Choose a secure password by following the guidelines in Section 3.1.

  • Protect your password, and change it often.

  • Check your last login messages each time you log in, and report any unexplained messages to your security administrator (Section 3.4.3).

  • Use proxy logins when possible (Section 3.4).

  • Log out and lock up when you leave your terminal and area (Section 3.11).

  • Use the /HANGUP qualifier with your final LOGOUT command from a dialup line (Section 3.11.4).

  • Properly dispose of hardcopy output from your terminal (Section 3.11.2).

  • Clear your screen, or turn off your video terminal to erase revealing displays (Section 3.6.2 and Section 3.11.1).

  • Lock up backup media. Anyone who has the media in hand can access the information that is stored on the tape or disk.

  • Ask your security administrator to enable security auditing for any protected objects, such as files, that you suspect have been accessed improperly (Section 3.10.3.1).

Chapter 4. Protecting Data

This chapter extends the discussion of security design introduced in Chapter 2. It describes how the operating system controls the way a user process or an application can access a protected object.

To summarize, the operating system controls access to any object that contains shareable information. These objects are known as protected objects. Devices, volumes, logical name tables, files, common event flag clusters, group and system global sections, resource domains, queues, capabilities, and security classes fall into this category. An accessing process carries credentials in the form of rights identifiers, and all protected objects list a set of access requirements specifying who has a right to access the object in a given manner.

This chapter:
  • Describes the types of identification the system assigns to processes to define their access rights to objects (Section 4.1)

  • Looks at the access controls that objects can hold (Section 4.2)

  • Shows how the operating system processes access requests (Section 4.3)

  • Explains how to control access to objects (Sections 4.4, 4.5, 4.6, 4.7)

Chapter 5 describes the unique features of each class of protected object.

4.1. Contents of a User's Security Profile

The profile of a user process or application includes the following elements:
  • User identification code (UIC) identifying the user

  • Rights identifiers held by the process

  • Privileges, if any

4.1.1. Per-Thread Security

OpenVMS Alpha Version 7.2 includes the implementation of thread-level security. This feature, known as per-thread security, allows each execution thread of a multithreaded process to run an independent security profile without impacting the security profiles of other threads in the process.

Security profile information previously contained in various process level data structures and data cells is now stored in a single data structure, the Persona Security Block (PSB), which is then bound to a thread of execution. All associated references within OpenVMS have been redirected accordingly. Every process in the system has at least one PSB that is the natural persona of the process. The natural persona is created during process creation.

Interaction between a thread manager (for example, the thread manager incorporated within VSI POSIX Threads Library) and the security subsystem provides for the automatic switching of profiles while threads are scheduled for execution.

4.1.2. Persona Security Block Data Structure (PSB)

The user's security profile (privileges, rights, and identity information) has shifted from the process level to the user thread level. The security information previously stored in several structures (including the Access Rights Block (ARB), Process Control Block (PCB), Process Header Descriptor (PHD), Job Information Block (JIB), and Control (CTL) region fields) has moved to a new Persona Security Block (PSB) data structure and all references are redirected accordingly. OpenVMS no longer uses some of the fields in these structures. The affected fields are now considered obsolete.

Each process has a persona array containing the addresses of all persona blocks allocated to the process.

The new persona block (PSB) contains the following:
  • UIC

  • Persona, and system rights chains

  • Permanent, authorized, and working privileges

  • Account name

  • User name

  • Auditing flags and counters

The kernel threads block (KTB) points to the persona block for the currently active thread.

4.1.3. Previous Security Model

In previous versions of OpenVMS, the information that constitutes a user's security profile was bound at the process level, common to all threads of execution within the process. Figure 4.1 illustrates this relationship.

Figure 4.1. Previous Per-Thread Security Model
Previous Per-Thread Security Model

Modifications made to the security profile by one thread are potentially visible to other threads, depending on how the threads perform profile management among themselves.

4.1.4. Per-Thread Security Model

In OpenVMS Version 7.2, each thread of execution can share a security profile with other threads or have a thread-specific security profile. Figure 4.2 illustrates these relationships.

Figure 4.2. Per-Thread Security Profile Model
Per-Thread Security Profile Model

As is the case in the previous model, modifications to a shared profile are potentially visible to all threads that share the profile. However, modifications made to a thread-specific security profile are only applicable to the particular thread.

4.1.5. User Identification Code (UIC)

The first element of a subject's security profile is the user identification code (UIC). Your UIC tells what system group you belong to and what your unique identification is within that group.

4.1.5.1. Format of a UIC

A UIC specification always appears in brackets, but its format can differ. Valid formats include the following:
  • An alphanumeric UIC consists of a member name and, optionally, a group name: [member] or [group,member]

    The group and member names can each contain up to 31 alphanumeric characters, at least one of which is alphabetic. The names can include upper- and lowercase characters A through Z, dollar signs ($), underscores (_), and the numbers 0 through 9.

  • A numeric UIC contains a group number and a member number: [group,member]

    The group number is an octal number in the range of 1 through 37776; the member number is an octal number in the range of 0 through 177776. You can omit leading zeros when you are specifying group and member numbers. VSI reserves group 1 and groups 300–377 for its own use.

The following table illustrates several UICs in proper UIC notation:

Type of UIC

Example

Meaning

Alphanumeric

[USER,FRED]

Group USER, member FRED

[EXEC,JONES]

Group EXEC, member JONES

[JONES]

Group EXEC, ? member JONES

Numeric

[200,10]

Group 200, member 10

[3777,3777]

Group 3777, member 3777

4.1.5.2. Guidelines for Creating a UIC

UICs cannot be arbitrarily assigned. A security administrator has to observe the following guidelines when creating them:
  • Member names must be unique for each user on the system.

  • No member can participate in more than one UIC group.

These guidelines exist because the system translates a UIC to a 32-bit value that represents a group number and a member number; the high-order 16 bits contain the group number, and the low-order 16 bits contain the member number. When translating an alphanumeric UIC such as [J_JONES], the operating system equates the member part of the alphanumeric UIC to both the group and member parts of a numeric UIC. The resulting 32-bit numeric UIC is kept in the rights database (which is a file containing information about identifiers, their attributes, and holders). For example, you could not have the two UICs [GROUP1,JONES] and [GROUP2,JONES] on the same system because the member JONES can have only one associated numeric UIC. The member name of the alphanumeric UIC is normally the same as the associated login user name.

4.1.5.3. How Your Process Acquires a UIC

When you log in to a system, the operating system copies your UIC from your user authorization (UAF) record in the system user authorization file (SYSUAF.DAT) and assigns it to your process. It serves as an identification for the life of the process.

By default, detached processes (created by the DCL command SUBMIT or RUN) and subprocesses (created by the DCL command SPAWN) take the same UICs as their creators. If you have IMPERSONATE privilege, you can create a detached process with a different UIC (by using the /UIC qualifier of the RUN command).

4.1.6. Rights Identifiers

The second element of a subject's security profile is a set of rights identifiers.

A rights identifier represents an individual user or a group of users. Using the Authorize utility (AUTHORIZE), security administrators create and remove identifiers and assign users to hold these identifiers. Rights identifiers can be a temporary way of identifying a group of users because users hold certain identifiers only as long as they are necessary.

4.1.6.1. Types of Identifiers

The operating system supports several types of rights identifiers. Table 4.1 shows the identifiers that are most commonly used in access control.
Table 4.1. Major Types of Rights Identifiers

Type

Description

Format

Example

Environmental identifiers

Describe different types of users based on their initial entry into the system.

Alphanumeric strings automatically created by the system. See Section 3.4 for details.

BATCH, NETWORK, INTERACTIVE, LOCAL, DIALUP, REMOTE

General identifiers

Defined by the security administrator.

Alphanumeric strings of 1 through 31 characters with at least one alphabetic character. Valid characters include numbers 0 through 9, characters A through Z and a through z, the dollar sign ($) and the underscore (_).

SALES, PERSONNEL, DATA_ENTRY, RESERVE_DESK

UIC identifiers

Based on a user's identification code (UIC), which uniquely identifies a user on the system and defines the group to which the user belongs.

Alphanumeric UICs, with or without brackets. Valid characters are the same as those for a general identifier.

[GROUP1,JONES], [JONES], GROUP1, JONES

Facility identifiers

Defined by the application.

Same as a general identifier. See the VSI OpenVMS Programming Concepts Manual for details.

DBM$MOD_SCHEMA

In addition to the identifiers listed in Table 4.1, a system node identifier of the form SYS$NODE_node_name is created by the system startup procedure (STARTUP.COM in SYS$SYSTEM).

4.1.6.2. Process and System Rights Lists

Associated with your process is a rights list that contains all the identifiers granted to it. In addition, there is a system rights list that is shared by all users on the system. The system manager or the system software grants identifiers to the system rights list that are granted to all users currently logged on to the system.

4.1.6.3. Displaying the Rights Identifiers of Your Process

You can display the identifiers for your current process with the SHOW PROCESS command, for example:
$ SHOW PROCESS/ALL
25-JUN-2008 15:23:18.08   User: GREG            Process ID:   34200094
                          Node: ACCOUNTS        Process name: "_TWA2:"
Terminal:           TWA2:
User Identifier:    [DOC,GREG]                1
Base priority:      4
Default file spec:  WORK1:[GREG.FISCAL_91]
Devices allocated:  ACCOUNTS$TWA2:
Process Quotas:
  .
  .
  .
Process rights:
 INTERACTIVE                                 2
 LOCAL                                       3
 SALES                                       4
 MINDCRIME                         resource  5

System rights:
 SYS$NODE_ACCOUNTS                         6
Output from this SHOW PROCESS command displays three types of identifiers:

1

UIC identifier, indicating user Greg is a member of the DOC group

2

Environmental identifier, indicating user Greg is an interactive user

3

Environmental identifier, indicating user Greg is logged in locally

4

General identifier, indicating user Greg is also a member of the SALES group

5

General identifier, indicating Greg holds the MINDCRIME identifier with the resource attribute so he can charge disk space to the identifier

6

Environmental identifier, indicating user Greg is working from the ACCOUNTS node

4.1.6.4. How Rights Identifiers Appear in the Audit Trail

The rights identifiers of a process also appear in audit records. If a security administrator chooses to audit access to objects, then the operating system can produce a record of which users accessed objects and when. Although a single audit record rarely tells very much, the trail of records can, over a period of time, reveal a pattern of behavior that tells a story.

The following audit record shows that user Greg attempted to delete a file but was prevented from doing so because he holds the identifier MINDCRIME. The file 93_FORECAST.DAT has an ACE preventing access by processes with the identifier MINDCRIME. (Relevant lines in the audit record are highlighted.)
Message from user AUDIT$SERVER on FNORD
Security alarm (SECURITY) and security audit (SECURITY) on ACCOUNTS,
                          system id: 19662
Auditable event:     Object deletion
Event information:   file deletion request (IO$_DELETE)
Event time:          24-APR-2008 13:17:24.59
PID:                 34200094
Process name:        _TWA2:
Username:            GREG
Process owner:       [DOC,GREG]
Terminal name:       TWA2:
Image name:          DSA2264:[SYS51.SYSCOMMON.][SYSEXE]DELETE.EXE
Object class name:   FILE
Object owner:        [SYSTEM]
Object protection:   SYSTEM:RWEDC, OWNER:RWEDC, GROUP:RE, WORLD:RE
File name:           _DSA2200:[GREG]93_FORECAST.DAT;1
File ID:             (17481,6299,1)
Access requested:    DELETE
Matching ACE:        (IDENTIFIER=MINDCRIME,ACCESS=NONE)
Sequence key:        00008A41
Status:              %SYSTEM-F-NOPRIV, no privilege for
                     attempted operation

4.1.7. Privileges

A third (optional) element of a subject's security profile is a set of privileges.

Privileges let you use or perform system functions that ordinarily would be denied to you. Security administrators can grant privileges to users under special circumstances so they can perform necessary tasks without changing existing protection authorizations.

Privileges vary in power. Some allow normal network operations; for example, NETMBX and TMPMBX let you send and receive mail across the network. But others, such as SYSNAM, grant the ability to influence system operations. A user with the SYSNAM privilege can modify the system logical name table.

A user's privileges are recorded in the user's UAF record in a 64-bit privilege mask. When a user logs in to the system, the user's privilege vector is stored in the subject's (process) security profile.

You can use the DCL command SET PROCESS/PRIVILEGES to enable and disable privileges for which you are are authorized, thus controlling the privileges available to the images you run. Example 4.1 shows user Puterman has a large number of authorized privileges, which are available for use when necessary, yet Puterman's process runs by default with only two privileges enabled: NETMBX and TMPMBX.
Example 4.1. Authorized Versus Default Process Privileges
$ SHOW PROCESS/PRIVILEGE
 8-OCT-2008 16:58:58.77
User: PUTERMAN  Process ID:   27E00496
Node: FNORD     Process name: "Hobbit"Authorized privileges:

 ACNT      ALLSPOOL  ALTPRI   AUDIT    BUGCHK   BYPASS  CMEXEC    CMKRNL
 DIAGNOSE  DOWNGRADE EXQUOTA  GROUP    GRPNAM   GRPPRV  IMPERSONATE IMPORT
 LOG_IO    MOUNT     NETMBX   OPER     PFNMAP   PHY_IO  PRMCEB    PRMGBL
 PRMMBX    PSWAPM    READALL  SECURITY SETPRV   SHARE   SHMEM     SYSGBL
 SYSLCK    SYSNAM    SYSPRV   TMPMBX   UPGRADE  VOLPRO  WORLD

Process privileges:
 NETMBX               may create network device
 TMPMBX               may create temporary mailbox
Puterman can enable specific authorized privileges as he needs them; for example, he needs ALLSPOOL to allocate a spooled device and LOG_IO to perform logical I/O operations.

4.2. Security Profile of Objects

4.2.1. Definition of a Protected Object

The objects of the OpenVMS operating system that require protection are all passive repositories that either contain or receive information. These objects are protected because once you have access to the object, you have access to the information it holds. Some examples of protected objects include:
  • A file in memory or on a storage device

  • A hardware device or a virtual device

  • A data structure, such as a common event flag cluster or a logical name table

Section 4.2.5 lists the classes of objects that OpenVMS protects; refer to Chapter 5 for an in-depth description of each class.

4.2.2. Contents of an Object's Profile

The security elements of any object comprise its security profile. An object's security profile contains the following types of information:
  • The owner of the object. The system uses this element in interpreting the protection code.

  • The protection code defining access to objects based on the categories of system, owner, group, and world. This protection code controls broad categories of users.

  • The access control list (ACL) controlling access to objects by individual users or groups of users.

With the exception of files, a new object inherits its security elements from a system-supplied template profile, which the site security administrator may modify. Files have a more complicated inheritance mechanism, one that affords greater control over the security elements of new objects. In all cases, you can assign security elements during object creation rather than using the operating system defaults.

This section gives an overview of protection codes and ACLs. Section 4.4 and Section 4.5 explore these protection mechanisms in greater detail. Refer to Chapter 5 for a description of individual object classes.

4.2.2.1. Owner

The first element of an object's security profile is the UIC of its owner.

In most cases, if you create an object, you are its owner. As the owner, you can modify its security profile. The system automatically assigns your UIC to the object and uses it in making access decisions.

There are some exceptions to the ownership rule. Files owned by resource identifiers do not have a UIC. When a user creates a file in the directory of a resource identifier, the file may be owned by the resource identifier and not the user who created the file (see Section 5.4.5). Refer to Chapter 5 for an explanation of the ownership rules for each object class.

The owner of any object except a file can reassign ownership to another user with the SET SECURITY/OWNER command, as described in Section 4.2.4. Changing the owner of a file usually requires privilege (see Section 5.4.2).

4.2.2.2. Protection Code

The second element of an object's security profile is the object's protection code.

The system automatically assigns a protection code to each new object. The protection code associated with an object determines the type of access allowed to a user, based on the relationship between the user UIC and the owner UIC With the exception of files and pseudo-terminal (FT) devices, the code a protected object receives is derived from a template profile for the class. (A file's protection code originates from another source, described in Section 5.4.)

Typically, you rely on the protection code to protect an object if the object is to be accessed by: (a) only the owner, (b) all users on the system, or (c) a specific UIC-based group of users. If you want to grant access to specific groups of users outside the UIC group but not to all users on the system, then you need to add an ACL (see Section 4.2.2.3).

Interpreting a Protection Code
A protection code defines the access rights for four categories of users: (a) the owner, (b) the users who share the same group UIC as the owner (the group category), (c) all users on the system (the world category), and (d) those with system privileges or rights (the system category). A code lists access rights in a fixed order: the system category (S), then owner (O), then group (G), and then world (W). It has the following syntax:
[user category: access allowed (,user category: access allowed,...)]

When the operating system processes a request to use a protected object, it compares the user's UIC to the UIC of the object's owner. If the user's UIC is the same as the UIC of the object's owner, the user is granted the access of the owner protection field. Failing a match of UICs, the system progresses through the other user categories. The system tries to find a match of the group fields to determine if there is a common group membership. The system may also evaluate whether the UIC group number indicates the user belongs to the system category of users. The world category applies to all users.

For example, user Jones has a UIC of [14,1], and he tries to read a file that is owned by UIC [14,5]. Because Jones is in the same group (14), the system might grant access to the file. The final decision depends on the access rights specified in the protection code.

See Section 4.5 for a complete description of how to interpret and create protection codes.

4.2.2.3. Access Control List (ACL)

The third (optional) element of an object's security profile is the object's access control list.

An access control list (ACL) is a collection of entries that define the access rights a user or group of users has to a particular protected object, such as a file, directory, or device.

ACLs may be created by default when an object is created, they may be created by the security administrator, or they may be created by users for objects to which they have control access (see Section 4.6.2).

Because security administrators can set up default ACLs, some users may be unaware that their objects have ACLs and may never change ACLs themselves. (You can use the DCL command DIRECTORY/SECURITY or SHOW SECURITY to see if there are ACLs on your files.) Other users are actively involved in creating and maintaining their own ACLs.

Using ACLs is optional. Although ACLs can enhance the security of objects in any installation through a more detailed definition of who is allowed what kind of access, users have to spend time creating and maintaining the ACLs.

You use the DCL commands SET SECURITY and SHOW SECURITY for creating and displaying ACLs, although the access control list editor (ACL editor) is an important utility for more extensive work.

Section 4.4 continues the discussion of ACLs and how to use them.

4.2.3. Displaying a Security Profile

To see the security profile of any protected object, use the DCL command SHOW SECURITY. For example, the following command requests security information about the file 93_FORECAST.TXT:
$ SHOW SECURITY 93_FORECAST.TXT

WORK_DISK$:[GREG]93_FORECAST.TXT;1 object of class FILE
Owner: [ACCOUNTING,GREG]
Protection: (System: RWED, Owner: RWED, Group: RE, World)
Access Control List: <empty>

The display indicates the file 93_FORECAST.TXT is owned by user Greg. It also lists the file's protection code, which gives read, write, execute, and delete access to system users and the owner. The code grants read and execute access to group users and provides no access to world users. (See Section 4.5 for further explanation.) There is no ACL on the file as yet.

4.2.4. Modifying a Security Profile

You can provide new values for the owner, protection code, or ACL of a protected object or even copy a profile from one object to another by using the SET SECURITY command.

For example, the SHOW SECURITY display in Section 4.2.3 shows the file 93_FORECAST.TXT is owned by user Greg. As owner, he can change the protection code for that file. Originally, the code gave no access to users in the world category. Now, Greg changes that to allow read and write access to world users:
$ SET SECURITY/PROTECTION=(W:RW) 93_FORECAST.TXT
The SHOW SECURITY command verifies the new protection code for the file:
$ SHOW SECURITY 93_FORECAST.TXT

93_FORECAST.TXT object of class FILE
Owner: [GREG]
Protection: (System: RWED, Owner: RWED, Group: RE, World: RW)
Access Control List: <empty>

Section 4.2.5 shows how to modify other elements in a profile. Section 4.4 and Section 4.5 discuss protection codes and ACLs extensively. For a full description of the SET SECURITY and SHOW SECURITY commands, see the VSI OpenVMS DCL Dictionary.

4.2.5. Specifying an Object's Class

Groups of objects that behave in a particular way and have a common set of attributes are divided into classes. Files, queues, and volumes are very common examples. As Table 4.2 shows, the operating system supports 11 classes of protected objects.

When you modify the profile of an object, you need to specify the class of the object; otherwise, the SET SECURITY command assumes the object is a file.

For example, the following command sequence changes the profile of an object and uses the /CLASS qualifier to identify the object LNM$GROUP as a logical name table:
$ SET SECURITY /CLASS=LOGICAL_NAME_TABLE-
_$ /OWNER=ACCOUNTING /PROTECTION=(S:RWCD, O:RWCD, G:R, W:R)-
_$ /ACL=((IDENTIFIER=CHEKOV,ACCESS=CONTROL),-
_$ (IDENTIFIER=WU,ACCESS=READ+WRITE)) LNM$GROUP

The SET SECURITY command makes the Accounting group owner of the logical name table. It changes the protection code to allow read, write, create, and delete access for the owner and for system users and to limit group and world users to read access. Finally, it creates an ACL to allow control access for user Chekov and to allow read and write access for user Wu.

The SHOW SECURITY command displays the results of the changes.
$  SHOW SECURITY LNM$GROUP /CLASS=LOGICAL_NAME_TABLE

LNM$GROUP object of class LOGICAL_NAME_TABLE
Owner: [ACCOUNTING]
Protection: (System: RWCD, Owner: RWCD, Group: R, World: R)
Access Control List:
     (IDENTIFIER=[USER,CHEKOV],ACCESS=CONTROL)
     (IDENTIFIER=[USER,WU],ACCESS=READ+WRITE)

Table 4.2. Classes of Protected Objects

Class Name

Definition

Capability

A resource to which the system controls access; currently, the only defined capability is the vector processor.

Common event flag cluster

A set of 32 event flags that enable cooperating processes to post event notifications to each other.

Device

A class of peripherals connected to a processor that are capable of receiving, storing, or transmitting data.

File

Files-11 On-Disk Structure Level 2 (ODS-2) files and directories.

Group global section

A shareable memory section potentially available to all processes in the same group.

Logical name table

A shareable table of logical names and their equivalence names for the system or a particular group.

Queue

A set of jobs to be processed in a batch, terminal, server, or print job queue.

Resource domain

A namespace controlling access to the lock manager's resources.

Security class

A data structure containing the elements and management routines for all members of the security class

System global section

A shareable memory section potentially available to all processes in the system.

Volume

A mass storage medium, such as a disk or tape, that is in ODS-2 format. Volumes contain files and may be mounted on devices.

Refer to Chapter 5 for a detailed description of each class.

4.2.6. Access Required to Modify a Profile

To modify a security profile, you need control access to the object. An ACL grants control access explicitly, whereas a protection code grants it implicitly to anyone who belongs to the owner or system category. (Refer to Section 4.6.2 for a full description of how you can acquire control access.)

4.3. How the System Determines If a User Can Access a Protected Object

When a user tries to access a protected object, the operating system calls the Check Protection ($CHKPRO) system service to compare the security profile of the user process with the security profile of the object. In the protection check, $CHKPRO compares the user's security profile against the protected object's profile using the following sequence:
  1. Evaluate the access control list (ACL).

    If the object has an ACL, the system scans it, looking for an entry that matches any of the user's rights identifiers. If a matching access control entry (ACE) is found, the system either grants or denies access, and further checking of the ACL stops.

    When the matching ACE denies access, a user can still gain access either through the system and owner fields of the protection code or through privilege. When an ACL has no matching ACE, the system checks all fields of the protection code.

  2. Evaluate the protection code. If the ACL did not grant access and the object's owner UIC is not zero, the operating system evaluates the protection code. The operating system grants or denies access based on the relationship between the user's identification code (UIC) and the object's protection code.

    For cases where an ACL has denied access, the system examines two fields in the protection code—the system and owner fields—to determine if the user is allowed access. The user can still acquire access by being a member of the system or owner categories or by possessing privileges. A user holding GRPPRV (with a matching group UIC) or SYSPRV is granted the access specified for the system category of the protection code.

  3. Look for special privileges.

    If access was not granted by the ACL or the protection code, privileges are evaluated.

    Users with certain system privileges may be entitled to access regardless of the protection offered by the ACLs or the protection code. The bypass privilege (BYPASS), group privilege (GRPPRV), read all privilege (READALL), or system privilege (SYSPRV) amplifies the holder's access to objects. (See Section 4.6.1 for more information on how privileges affect access.)

  4. Consider access overrides.

    For some object classes, access may be granted based on alternate privileges. For example, the queue object allows full access to all queues for users with operator privilege (OPER), and the logical name table object allows access to the system table for users with system name privilege (SYSNAM).

Figure 4.3 charts the sequence the operating system follows when it evaluates an access request and shows how the controlling components (ACLs, protection codes, privileges, and access overrides) interact.

Figure 4.3. Flowchart of Access Request Evaluation
Flowchart of Access Request Evaluation

4.4. Controlling Access with ACLs

Section 4.2.2.3 introduced access control lists (ACLs) as one element of an object's security profile. This section explores this protection mechanism in depth and provides examples of how to use ACLs effectively to protect objects.

Many users do not need to bother with ACLs because the protection codes that the operating system automatically assigns to objects are often sufficient. But there are times when you need to allow specific users access to your files, for example, when you are working on a common project. Because ACLs are an effective mechanism for protecting critical system files, devices, volumes, and other protected objects, system managers and security administrators use ACLs more often than general users.

4.4.1. Using Identifier Access Control Entries (ACEs)

Each entry in an access control list (ACL) is called an access control entry (ACE). An ACL can have many entries, each of which defines some attribute of an object. There are many kinds of ACEs, which you can read about in the VSI OpenVMS System Management Utilities Reference Manual. Of interest here is the Identifier ACE, which controls access to objects.

An Identifier ACE includes one or more rights identifiers and a list of the types of access the users holding the identifier have permission to exercise. When the system evaluates a user's rights to an object, it scans the object's ACL until it finds an Identifier ACE that matches one or more rights identifiers held by the accessing user; it grants or denies access based on that entry.

The types of access that are granted (or denied) by an ACE depend on the object you are protecting. For example, you can read, write to, execute, and delete a file; whereas you can perform physical and logical operations on a device as well as reading and writing to it. Thus, a file supports read, write, execute, and delete access, and a device supports read, write, physical, and logical access. See Chapter 5 for information on the types of access other object classes support.

To create an ACL with an Identifier ACE, use the DCL command SET SECURITY in the following format:
SET SECURITY/ACL=(IDENTIFIER=identifier,ACCESS=access-type)
For example, to let user Fred read your file PROJECT-DATA.TXT, you would enter the following command:
$ SET SECURITY/ACL=(IDENTIFIER=FRED,ACCESS=READ) PROJECT-DATA.TXT

The term FRED is the member name of a user identification code (UIC). As such, it serves as a UIC identifier for the entry that grants user Fred read access to the file PROJECT-DATA.TXT.

4.4.2. Granting Access to Particular Users

Because identifiers define the rights of individual users or groups of users (see Section 4.1.6.1), you use them in an Identifier ACE to define the access granted (or denied) to those who hold them. A UIC identifier easily identifies an individual user or a group of users on the system. When a group of users from diverse functional groups (and therefore, diverse UIC groups) all need access to a protected object, a security administrator creates a general identifier and grants the identifier to all the users who need access.

For example, the following command grants user Pat, who is identified by the UIC identifier [PAT], read, write, and execute access to a file located in the ROBERTS directory on DISK1. The ACL denies Pat delete and control access because it omits them from the access statement.
$ SET SECURITY/ACL=(IDENTIFIER=[PAT],ACCESS=READ+WRITE+EXECUTE)-
_$ DISK1:[ROBERTS]JULY-SALES.TXT
A security administrator uses the Authorize utility to create a general identifier and grant it to all users who need to use it. Assume, for example, that a security administrator has created and assigned the identifier PAYROLL to employees who need access to a payroll file. For the holders of the identifier to actually access the file, the administrator has to add an Identifier ACE to the file. For example, the following command creates an ACL for the PAYROLL file that gives holders of the PAYROLL identifier read access to the file:
$ SET SECURITY/ACL=(IDENTIFIER=PAYROLL,ACCESS=READ) PAYROLL.DAT

The order of ACEs in an ACL is important because of the operating system's processing rules. See Section 4.4.6 for information on ordering ACEs.

4.4.3. Preventing Users from Accessing an Object

Besides providing access to objects, an Identifier ACE is often used to deny certain users access to an object. Some sites might use an ACL to restrict users who log in from a modem or over the network. Other sites might place a restricting ACE on expensive equipment or volumes containing sensitive files.

To deny all access to holders of a particular identifier, use the NONE keyword as the access type name. For example, the following command denies holders of the environmental identifier DIALUP any access to the files in the PROJECT-ACCOUNTS directory:
$ SET SECURITY/ACL=(IDENTIFIER=DIALUP,ACCESS=NONE)-
_$ /CLASS=FILE PROJECT-ACCOUNTS.DIR

Denying access with the NONE keyword requires some additional planning. You must position the ACE correctly in the ACL, as Section 4.4.6 describes, because the operating system grants or denies access based on the first matching ACE. Alternatively, you can eliminate any access allowed through the group or world category of the protection code (see Section 4.3 and Section 4.5.5, in particular.) Security administrators may also want to rescind privileges that can override the matching ACE.

4.4.4. Limiting Access to a Device

Although a security administrator may want to provide access to a common file, such as the payroll file described in Section 4.4.2, the administrator would want to ensure that only a limited number of people could use the letter-quality printer designated for printing checks. Otherwise, any holder of the payroll identifier could access the check forms that are always loaded in the printer TTA8.

Because the check printer in the current example is never used for logins and no queues are directed to it, the security administrator can add an ACL to the printer to ensure that only one user, McGrey, is allowed read and write access. At the same time, the administrator must block printer access for all other identifier holders. The following command sequence creates such an ACL:
$ SET SECURITY/ACL=((IDENTIFIER=MCGREY,ACCESS=READ+WRITE)-
_$ (IDENTIFIER=*,ACCESS=NONE))/CLASS=DEVICE TTA8

While McGrey acquires read and write access, all other users are denied access with the NONE keyword, explained in Section 4.4.3. Still, the ACL on the printer TTA8 might not work exactly as intended until the security administrator modifies the printer's protection code. See Section 4.5.5 for details.

4.4.5. Limiting Access to an Environment

With an Identifier ACE, it is possible to provide conditional access by combining certain kinds of identifiers. A common situation is to use a UIC identifier with one of the environmental identifiers like batch or interactive. (For a complete list of environmental identifiers, see Section 4.1.6.1.) Thus, a user can access a protected object only when running in batch mode or interactively but never over a dialup line. For example, the next command grants user Fred both submit and manage access to a print queue, but only while he is running a batch job:
$ SET SECURITY/ACL=(IDENTIFIER=[FRED]+BATCH,ACCESS=SUBMIT+MANAGE)-
_$ /CLASS=QUEUE SYSTEM6$LPA0

4.4.6. Ordering ACEs Within a List

An ACL can contain one entry or many entries. With multiple ACEs, the order of the entries is critical because the system determines access based on the first matching ACE. The operating system searches an ACL sequentially and grants a user the access specified in the first matching ACE, thus ignoring all subsequent entries. See Section 4.3 for a description of the evaluation process.

When writing ACLs, keep the following principles in mind:
  • ACEs giving access to critical users belong at the top of the list.

  • ACEs giving specific access to smaller groups belong before ACEs giving access to larger groups.

  • ACEs giving more access rights belong before ACEs giving fewer access rights, unless you mean to selectively deny access.

The following ACL on the directory file PROJECT-ACCOUNTS.DIR demonstrates how to order entries in an ACL. It places ACEs giving access to critical users (Jones and Fred) at the top of the list and places general ACEs after them. The ACE denying access goes at the end.
$ SET SECURITY/ACL=( -
_$ (IDENTIFIER=[ACCOUNTING,JONES],ACCESS=READ+WRITE+EXECUTE),-
_$ (IDENTIFIER=[FRED]+BATCH,ACCESS=READ+WRITE+EXECUTE),-
_$ (IDENTIFIER=PAYROLL,ACCESS=READ),-
_$ (IDENTIFIER=DIALUP,ACCESS=NONE)) PROJECT-ACCOUNTS.DIR

The ACL on the project accounts directory allows read, write, and execute access to Jones all the time and to Fred while he is running a batch job. It gives read access to users holding the PAYROLL identifier. All users who are logging in from a modem are denied access unless they gain access through an earlier ACE. For example, Jones, Fred, or holders of the PAYROLL identifier might be dialing in, but, because their ACE precedes the DIALUP ACE, they would be granted access.

The next example shows an ACL for the data file STAFFING.DAT. It demonstrates how you place the entry providing the greatest amount of file access at the top of an ACL.
$ SET SECURITY/ACL=( -
_$ (IDENTIFIER=SECURITY,OPTIONS=PROTECTED,ACCESS=READ+WRITE+EXECUTE+DELETE+CONTROL),-
_$ (IDENTIFIER=PERSONNEL,ACCESS=READ+WRITE+EXECUTE+DELETE),-
_$ (IDENTIFIER=SECRETARIES,ACCESS=READ+WRITE),-
_$ (IDENTIFIER=[PUB,*],ACCESS=READ),-
_$ (IDENTIFIER=NETWORK,ACCESS=NONE),-
_$ (IDENTIFIER=[SALES,JONES],ACCESS=NONE)) STAFFING.DAT

In this ACL, any users holding the SECURITY identifier obtain maximum access rights through the first ACE, and users holding the PERSONNEL identifier have the next greatest access. User Jones is prohibited from any access to the file unless Jones also happens to hold one of the general identifiers. (This might be an oversight on the part of the creator of the ACL.) If you want to be absolutely certain that user Jones cannot gain access to the file, move the entry at the bottom of the ACL to the top.

4.4.7. Establishing an Inheritance Scheme for Files

You can create a plan for controlling access to files within a directory or a directory structure, develop an appropriate ACL for the files, and then direct the operating system to automatically assign this ACL to new files. To do this, create an Identifier ACE with the Default attribute, and then add the ACE to the directory file cataloging the files you want to affect. Use the OPTIONS keyword to include the Default attribute.

For example, if you want all new files in the directory [MALCOLM] to have an ACL entry that permits read and write access to users with the PERSONNEL identifier, you can add the following ACE to the file MALCOLM.DIR:
$ SET SECURITY/ACL=(IDENTIFIER=PERSONNEL,OPTIONS=DEFAULT,-
_$ ACCESS=READ+WRITE)  [000000]MALCOLM.DIR
As a result of this ACE, any file created in the [MALCOLM] directory has the following ACL:
$ SHOW SECURITY APRIL_INTERVIEWS.TXT

WORK_DISK$:[MALCOLM]APRIL_INTERVIEWS.TXT;1 object of class FILE

Owner: [SALES,MALCOLM]
Protection: ...
Access Control List:
     (IDENTIFIER=PERSONNEL,ACCESS=READ+WRITE)
  .
  .
  .

Notice that the Default attribute does not appear within a new file's ACL but only in the ACL of directory files. However, any subdirectory created in the MALCOLM directory automatically has the entry (IDENTIFIER=PERSONNEL,OPTIONS=DEFAULT,ACCESS=READ+WRITE) as part of its ACL. In this way, the ACE is propagated throughout the entire directory tree.

The ACE is not applied retroactively to existing versions of files in MALCOLM.DIR. To attach an ACE to existing files, you can use the /DEFAULT qualifier, described in Section 4.5.7, or use the following command:
$ SET SECURITY/ACL=(IDENTIFIER=PERSONNEL,ACCESS=READ+WRITE)-
_$ [MALCOLM]*.*;*
Any ACE with a Default attribute controls only the propagation of the ACE; it has no effect on access control. To control access to the directory as well as all its files, you have to insert two ACEs in the directory's ACL, as follows:
$ SET SECURITY/ACL=-
_$ ((IDENTIFIER=PERSONNEL,ACCESS=READ+WRITE),-
_$ (IDENTIFIER=PERSONNEL,OPTIONS=DEFAULT,ACCESS=READ+WRITE))-
_$ [000000]MALCOLM.DIR

4.4.8. Displaying ACLs

The DCL command SHOW SECURITY displays an object's ACL. When working with objects other than files, you must supply a class name as well as the object name. For example, the following display shows the security attributes of a device called PPA0. It is owned by the operating system, and its protection code gives full access (read, write, physical, and logical) to users in the system and owner categories but no access to group and world users; its ACL gives control access to user Svensen.
$ SHOW SECURITY /CLASS=DEVICE PPA0:

_ACCOUNTS$PPA0: object of class DEVICE

Owner: [SYSTEM]
Protection: (System: RWPL, Owner: RWPL, Group, World)
Access Control List:
    (IDENTIFIER=[ADMIN,SVENSEN],ACCESS=CONTROL)
There are many other ways of displaying ACLs. The access control list editor (ACL editor) is a useful tool for extensive work with ACLs; see the ACL editor documentation in the VSI OpenVMS System Management Utilities Reference Manual. But any of the following DCL commands display ACLs:
  • SHOW SECURITY
  • DIRECTORY/ACL
  • DIRECTORY/SECURITY
  • DIRECTORY/FULL
  • SHOW LOGICAL/FULL/STRUCTURE
  • SHOW DEVICE/FULL
  • SHOW QUEUE/FULL

Applications sometimes add a Hidden attribute to an ACE to indicate that the ACE should be changed only by the application that adds the ACE. Unless users have the SECURITY privilege, they cannot display a hidden ACE by using DCL commands. The ACL editor does display ACEs holding the Hidden attribute but only to show its relative position within the ACL; however, unauthorized users cannot edit the ACE.

Sometimes you see other kinds of ACEs, unrelated to access control, in an ACL. For example, if the security administrator places a security-auditing ACE on the LN03$PRINT queue, you will see an ACE at the top of the list that has the format (AUDIT=SECURITY,ACCESS= access-types). Such an ACE is part of the security-auditing system and has no effect on access, so you can ignore it.

4.4.9. Adding ACEs to an Existing ACL

Section 4.4.2 through Section 4.4.5 discuss how to add entries to an empty ACL with the DCL command SET SECURITY. To modify ACLs extensively, use the ACL editor; however, in many cases the SET SECURITY command is more appropriate. This section and those that follow describe how to use SET SECURITY to change an ACL.

To add more entries to an ACL, you can use the /ACL qualifier with the SET SECURITY command and specify the new ACEs. For example, to give the writers access to the print queue LN03$PRINT, use the following command:
$ SET SECURITY/CLASS=QUEUE/ACL=(IDENTIFIER=WRITERS,-
_$ ACCESS=READ+WRITE)  LN03$PRINT
By default, the system places the new ACE at the top of the ACL, as you see in the following SHOW SECURITY display:
$  SHOW SECURITY /CLASS=QUEUE LN03$PRINT

_LN03$PRINT: object of class QUEUE

Owner: [SYSTEM]
Protection: (System: RWPL, Owner: RWPL, Group, World)
Access Control List:
     (IDENTIFIER=WRITERS,ACCESS=READ+WRITE)
     (IDENTIFIER=[PUB,*],ACCESS=READ)
     (IDENTIFIER=NETWORK,ACCESS=NONE)
Because the default behavior for SET SECURITY is to place a new ACE at the top of an ACL, you need to use the /AFTER qualifier if you want to put the ACE in another position. For example, to position the TRADERS ACE in the queue's ACL after the WRITERS ACE:
$ SET SECURITY/CLASS=QUEUE/ACL=(IDENTIFIER=TRADERS,ACCESS=WRITE)-
_$ /AFTER=(IDENTIFIER=WRITERS,ACCESS=READ+WRITE) LN03$PRINT
The resulting display confirms the effectiveness of the /AFTER qualifier. The new ACE is put second in the list.
$  SHOW SECURITY /CLASS=QUEUE LN03$PRINT

_LN03$PRINT: object of class QUEUE

Owner: [SYSTEM]
Protection: (System: RWPL, Owner: RWPL, Group, World)
Access Control List:
     (IDENTIFIER=WRITERS,ACCESS=READ+WRITE)
     (IDENTIFIER=TRADERS,ACCESS=WRITE)
     (IDENTIFIER=[PUB,*],ACCESS=READ)
     (IDENTIFIER=NETWORK,ACCESS=NONE)

4.4.10. Deleting an ACL

The /DELETE qualifier on the SET SECURITY command erases an ACL. Depending on how the qualifier is used, you can delete all or part of an ACL. For example, the following command deletes a disk's ACL:
$ SET SECURITY/CLASS=DEVICE/ACL/DELETE DUA0

An ACE can be protected against inadvertent deletion if it holds the Protected attribute. To eliminate a protected ACE, you need to delete it explicitly or use the /DELETE=ALL qualifier on the SET SECURITY/ACL command.

4.4.11. Deleting ACEs from an ACL

You can eliminate a subset of an ACL by listing the unwanted ACEs with the /ACL qualifier and including the /DELETE qualifier. For example, the following command deletes the ACEs giving holders of the TRADERS identifier and the NETWORK identifier write access to volume DBA0:
$ SET SECURITY/CLASS=VOLUME/ACL=-
_$ (IDENTIFIER=TRADERS,ACCESS=WRITE),- 
_$ (IDENTIFIER=NETWORK,ACCESS=WRITE)/DELETE DBA0:

4.4.12. Replacing Part of an ACL

To replace one contiguous set of ACEs within an ACL with another set, specify the new ACEs with the /REPLACE qualifier and the ACEs to be deleted with the /ACL qualifier, as follows:
$ SET SECURITY/CLASS=VOLUME/ACL=(IDENTIFIER=TRADERS,ACCESS=WRITE)-
_$ /REPLACE=((IDENTIFIER=RESEARCH,ACCESS=WRITE)-
_$ (IDENTIFIER=STATE_DEPARTMENT,ACCESS=READ+WRITE),-
_$ (IDENTIFIER=ENERGY_DEPARTMENT,ACCESS=READ+WRITE)-
_$ DBA0:

The TRADERS ACE specified by /ACL is deleted. Following the deletion, the ACEs specified by the /REPLACE qualifier (RESEARCH, STATE_DEPARTMENT, ENERGY_DEPARTMENT) are inserted at the location of the old ACE.

4.4.13. Restoring a File's Default ACL

If you want to restore the default ACL to a file, you can use the /DEFAULT qualifier to the SET SECURITY command. This qualifier regenerates the full security profile for a file. See Section 4.5.7 for a description.

4.4.14. Copying an ACL

You can copy the security profile of one object to another by using the /LIKE qualifier to the SET SECURITY command. For example, you can save a complicated ACL on a nonpermanent object like a logical name table by copying it to a permanent object such as a file. Some administrators create a file to serve as a template in copy operations. This way, they can easily transfer an ACL from one object to another. For example, the following command copies the ACL from file ACL_TEMPLATE.TXT to the logical name table LNM$GROUP:
$ SET SECURITY/LIKE=NAME=ACL_TEMPLATE.TXT-
_$ /COPY_ATTRIBUTE=ACL/CLASS=LOGICAL_NAME_TABLE LNM$GROUP
If you add the /COPY_ATTRIBUTE qualifier to the /LIKE qualifier, then you can copy one or two elements rather than the complete profile. Notice the ACL on the following directory, KITE_FLYING:
$ SHOW SECURITY [000000]KITE_FLYING.DIR;1 -

WORK_DISK$:[000000]KITE_FLYING.DIR;1 object of class FILE

Owner: [PROJECTX]
Protection: (System: RWED, Owner: RWED, Group:, World)
Access Control List:
     IDENTIFIER=PROJECTX,ACCESS=READ+WRITE+EXECUTE
     IDENTIFIER=PROJECTX,OPTIONS=DEFAULT,ACCESS=READ+WRITE+EXECUTE
The following command copies the ACL from directory KITE_FLYING to the directory KITE_DESIGNS:
$ SET SECURITY/LIKE=KITE_FLYING.DIR;1 -
_$ /COPY_ATTRIBUTE=ACL KITE_DESIGNS.DIR;1

$ SHOW SECURITY [000000]KITE_DESIGNS.DIR;1 -

WORK_DISK$:[000000]KITE_DESIGNS.DIR;1 object of class FILE

Owner: [ENGINEERING]
Protection: (System: RWED, Owner: RWED, Group:R, World:R)
Access Control List:
     IDENTIFIER=PROJECTX,ACCESS=READ+WRITE+EXECUTE
     IDENTIFIER=PROJECTX,OPTIONS=DEFAULT,ACCESS=READ+WRITE+EXECUTE

The SET SECURITY/LIKE command does not always duplicate the entire ACL of the source object. For example, the command does not copy any ACEs from the source ACL that have the Nopropagate attribute. The command also does not overwrite protected ACEs. It preserves protected ACEs on the target object and adds them to the ACL being copied. (For example, applications often use a special type of protected ACE to explain how to display file data correctly, and these ACEs have to be preserved.)

Refer to the ACL editor documentation in the VSI OpenVMS System Management Utilities Reference Manual for details on the different attributes an ACE can have, and refer to the VSI OpenVMS Programming Concepts Manual for a description of all ACE types.

4.5. Controlling Access with Protection Codes

A protection code controls the type of access allowed (or denied) to a particular user or group of users. Access types identify the capabilities required to perform an operation on a protected object. The operating system can have multiple access requirements to complete an operation (see Section 4.7.2). A user can gain access to an object as soon as the operating system finds a category within the protection code for which the user qualifies that allows the access requested (provided an ACL does not deny access).

4.5.1. Format of a Protection Code

A protection code has the following format:
[user category: list of access allowed (, user category: list of access allowed,...)]

user category

User categories include system (S), owner (O), group (G), and world (W). Each category can be abbreviated to its first character. Categories have the following definitions:
  • System: Members of this category can include any of the following:
    • Users with low group numbers, usually from 1 to 10 (octal). These group numbers are generally for system managers, security administrators, and system programmers. (The exact range of system group numbers is determined by the security administrator in the setting of the system parameter MAXSYSGROUP. It can range as high as 37776 (octal).)

    • Users with the SYSPRV privilege.

    • Users with the GRPPRV privilege whose UIC group matches the UIC group of the object's owner.

    • In access requests to files on a disk volume, users whose UIC matches the UIC of the volume's owner.

  • Owner: The user with the same UIC as the user who currently owns the object. In general, the creator of an object is entitled to owner access unless explicit action is taken to secure the object from its creator.

  • Group: All users who are in the same UIC group as the object's owner.

  • World: All users, including those in the first three categories.

When specifying more than one user category, separate the categories with commas, and enclose the entire code in parentheses. You can specify user categories and access types in any order (although the system always displays them in the order system, owner, group, world).

To deny all access to a user category, specify the user category without any access types. Omit the colon after the user category when you are denying access to a category of users.

Omitting a category entirely means access to the category is unspecified. The current access allowed that category of user remains unchanged. If the protection code applies to an object being created (for example, with a COPY/PROTECTION command), the omitted category is assigned the default value.

access-list

Access types are object-dependent and are described in Chapter 5. For files, the access types include read (R), write (W), execute (E), and delete (D). The access type is assigned to each user category and is separated from its user category by a colon (:), for example, SET SECURITY/PROTECTION=(S:RWE,O:RWE,G:RE,W).

4.5.2. Types of Access in a Protection Code

Each category of user can be allowed or denied different types of access. The exact type is dependent on the object being protected. Each object class defines access types appropriate for its class and representative of the ways in which users operate on the data. For example, while the file object supports read, write, execute, and delete access, devices (such as terminals, printers, and disks) support read, write, physical I/O, and logical I/O access. See Chapter 5 for a listing of the access types each object class supports.

All protected objects also support control access, which allows a user to examine and modify the security elements (ACL, protection code, UIC) and possibly other attributes of the object. Control access is explicitly stated in an ACL but never appears in the UIC-based protection code. All users who qualify for the system or owner categories of a protection code have control access. Users in the group and world categories never receive control access through a protection code, but they could receive access through an ACL. See Section 4.6.2 for more information.

The capabilities conveyed by the access types read, write, execute, delete, and control vary depending on the situation where they apply. For example, execute access permits different operations depending on whether it is granted for file access or directory access. Chapter 5 explains the capabilities that each access type allows for each type of protected object.

4.5.3. Processing a Protection Code

When the system evaluates a protection code, it looks first at the owner field, then at the world field, the group field, and finally the system field. As soon as a user qualifies as a member of the category and that category grants the necessary access, the operating system stops processing the code (see Figure 4.3).

The following protection code specifies that users in the system and owner categories have read (R), write (W), execute (E), and delete (D) access, while users in the group and world categories have only read and execute access:
$ SET SECURITY/PROTECTION=(SYSTEM:RWED, OWNER:RWED, GROUP:RE, WORLD:RE)-
_$ TAXES_91.DAT

When you want to deny access to a user category, you must deny access to all the outermost categories. As Section 4.5.1 shows, any user process or application qualifies for world access. The group category is more restrictive yet not as restrictive as the owner and system categories.

The following protection code, for example, appears to deny delete access to the owner category:
$ SHOW SECURITY TAXES_91.DAT

WORK_DISK$:[GREG]TAXES_91.DAT;1 object of class FILE
Owner: [FINANCE,GREG]
Protection: (System: RWED, Owner: RW, Group:RW, World:RWED)
Access Control List: ...
However, the owner of the file can still delete the file. Although delete access is not allowed through the owner category, the system continues to check the remaining categories for permission to grant access. Because the owner also fits in the world category (which applies to all users) and the world category is permitted delete access, the system grants delete access to the owner.

4.5.4. Changing a Protection Code

You can change the UIC-based protection on an existing object with the SET SECURITY command. The following command modifies the protection code of the file SURVEY.DIR so that anyone in the system and owner categories has read, write, execute, and delete access; whereas members of the group and world categories have read and execute access:
$ SET SECURITY/PROTECTION=(SYSTEM:RWED,OWNER:RWED, -
_$ GROUP:RE,WORLD:RE)  SURVEY.DIR
Whenever you omit a category from a protection code, the current access remains unchanged. For example, consider the protection code for the file RECORDS_91.DAT:
$ SHOW SECURITY RECORDS_91.DAT

WORK_DISK$:[GREG]RECORDS_91.DAT object of class FILE
Owner: [VMS,GREG]
Protection: (System: RWED, Owner: RWED, Group: RWED, World: RE)
As it stands, the file RECORDS_91 allows read, write, execute, and delete access to users in the system, owner, and group categories; it allows read and execute access to users in the world category. The following DCL command resets the protection code for RECORDS_91.DAT to deny write and delete access to the group category and to deny all access to the world category:
$ SET SECURITY/PROTECTION=(G:RE,W) RECORDS_91.DAT
The next command confirms the modified protection code. It shows that the system and owner categories of users continue to hold read, write, execute, and delete access, while group users have only read and execute access and world users have no access.
$ SHOW SECURITY RECORDS_91.DAT
WORK_DISK$:[GREG]RECORDS_91.DAT object of class FILE
Owner: [VMS,GREG]
Protection: (System: RWED, Owner: RWED, Group: RE, World:)

4.5.5. Enhancing Protection for Sensitive Objects

Section 4.4.4 describes how to place an ACL on an important printer so that only one user can have access to it. Before the ACL can be effective, however, the security administrator has to eliminate all access provided through the printer's protection code by using the following command:
$ SET SECURITY/PROTECTION=(S,O,G,W)/CLASS=DEVICE TTA8:
The security administrator then uses an ACL to assign access explicitly.
For example, to limit access to a queue, you can remove submit access for the world category. Then you can set up an ACL that specifies which users (from the world category) are permitted to submit jobs to the queue. The following command stipulates that only holders of the identifier PROJECTX can submit jobs to the LN03$PRINT queue:
$ SET SECURITY/CLASS=QUEUE/PROTECTION=(W) -
_$ /ACL=(IDENTIFIER=PROJECTX,ACCESS=SUBMIT) -
_$ LN03$PRINT

Important files frequently need special protection. You can prevent users from seeing the contents of a directory by denying them read access. To further protect the files, you can add a Default Protection ACE to the directory file, as Section 4.5.6 describes.

4.5.6. Providing a Default Protection Code for a Directory Structure

To specify default protection for new files in a particular directory, place a Default Protection ACE in the ACL of the directory file. The Default Protection ACE affects files that are subsequently created in the directory and in any subdirectories under that directory unless protection is specified for one of those files individually. This ACE type has the following format:
(DEFAULT_PROTECTION[,options],protection-code)
For example, the following ACE specifies that users in the system and owner categories have read, write, execute, and delete access to any files subsequently created in the directory and that group and world users have no access:
$ SET SECURITY/ACL=(DEFAULT_PROTECTION,S:RWED,O:RWED,G,W) ARCHIVE.DIR
Be aware that the default protection is associated only with newly created files – not existing files in the current directory and its subdirectories. If you add a Default Protection ACE to a directory file and want the same protection applied to existing files, you must explicitly change the protection with the following command:
$ SET DEFAULT [ARCHIVE]
$ SET SECURITY/PROTECTION=(S:RWED,O:RWED,G,W) [...]*.*;*

4.5.7. Restoring a File's Default Security Profile

The /DEFAULT qualifier of the SET SECURITY command regenerates the security profile of a file. The /DEFAULT qualifier resets the protection code, the ACL, and the owner elements of the file to the defaults specified by the file's parent directory (that is, to the directory's default ACL, default protection ACE, if any, and owner UIC).

The profile is recreated according to the following rules:
  • The protection code is propagated from the Default Protection ACE on the directory (if one exists), or else it is propagated from the process default.

  • The ACL is propagated from the parent directory for those ACEs that have the Default attribute.

  • The owner is set to the owner of the parent directory. (Be aware that modifying a file's owner generally requires privilege; see Section 5.4.2.)

With subdirectory files, SET SECURITY assigns the owner, protection, and ACL elements of the parent directory. SET SECURITY does not copy any ACE on the source object if it holds the Nopropagate attribute, nor does it change any ACE on the target object if it holds the Protected attribute. To apply new elements to all versions of the file, specify ;* in the object name.

Refer to Section 5.4.5 for more information on propagation rules.

4.6. Understanding Privileges and Control Access

Although an object can be carefully protected by an ACL and a protection code, a user can still gain access through the use of privilege or control access.

4.6.1. How Privileges Affect Protection Mechanisms

Security administrators can assign privileges to users when they create or modify user accounts. The system privileges READALL and BYPASS affect user access, regardless of the access dictated by an ACL for the object or by other elements in its security profile. The privileges SYSPRV and GRPPRV are controlled through the system category of the protection code. The privileges have the following meanings:

BYPASS

A user with BYPASS privilege receives all types of access to the object, regardless of its protection.

GRPPRV

A user with GRPPRV privilege whose UIC group matches the group of the owner of the object receives the same access accorded to users in the system category. Thus, the user with GRPPRV privilege is able to manage any of the group's objects.

READALL

A user with READALL privilege receives read access to the object, even if that access is denied by the ACL and the protection code. In addition, the user can receive any other access granted through the protection code.

SYSPRV

A user with SYSPRV privilege receives the access accorded to users in the system category.

When you define ACLs or protection codes for your objects, remember that users with amplified privileges are entitled to special access to objects throughout the system. For example, there is no way to stop a user with the BYPASS privilege from accessing your files. Users with GRPPRV privilege have the power to perform many system management functions for other members of their UIC group. Protection of your objects depends on the judgment of your security administrator in granting these privileges.

4.6.2. Using Control Access to Modify an Object Profile

Any user with control access to an object can change its protection code and ACL and thereby gain access to an object. For all object classes but files, control access also allows a user to modify the object's owner. To modify the owner of a file generally requires privilege (see Section 5.4.2).

You obtain control access in any of the following ways:
  • You hold an identifier to which the object's ACL gives control access.

  • You have the same UIC as the owner of the object.

  • You qualify as a member of the system user category, and the object has an owner with a nonzero UIC. For example, you hold GRPPRV (with a matching group UIC) or SYSPRV. (Refer to Section 4.5 for a full description of system users.)

  • You hold BYPASS privilege.

Sometimes object classes allow control access through other means. Refer to Section 4.6.3 and to the individual descriptions of classes in Chapter 5 for any special conditions that may apply.

4.6.3. Object-Specific Access Considerations

For some objects, access can be granted either by a special privilege (beyond those listed in Section 4.6.1) or by an all-inclusive type of access. This is particularly true of a queue. A user with operator (OPER) privilege is granted all types of access to a queue. A user with manage access implicitly possesses the three other types of queue access: read, submit, and delete. Chapter 5 lists each object class with its access types and meanings and any special privilege.

4.7. Auditing Protected Objects

Whenever a process uses an object or modifies its security profile (see Section 4.2.4), the system can send an alarm to an operator terminal or write a message to the audit log file. By reading the log file, a security administrator can review system activity to see how protected objects are being used, when they are being used, and who is using them.

Exactly which type of information is reported through the auditing system depends on how the security administrator defines the site's requirements. If system administrators choose to have object use audited, they can enable auditing for the appropriate categories of events.

The operating system can filter security-related events and send system administrators messages only when objects are accessed in certain ways. Sites are often more interested in the privileged use of a file or the failure to access a file than in every file access. Such a site can request auditing messages whenever a process fails in accessing a file, but not when it is successful. The system can report how the process exercised, or failed to exercise, the right to access the object in the first place: through a protection code, an ACE, or a privilege.

4.7.1. Kinds of Events the System Audits

Each object class has its own auditing profile, described in Chapter 5, and so it is possible to receive more information on some classes of objects than on others. For any object, the system can send an auditing message whenever a user or application accesses the object or modifies its security elements. In some instances, the system can send a notification when a process creates an object, stops using it (deaccesses it), or deletes it.

4.7.2. Enabling Auditing for a Class of Objects

When you are auditing object access events, keep in mind that the operating system may check a user's right to an object several times during a single operation. A file operation, for example, can involve checks for both directory and file access. Before a user deletes a file, the system checks for delete access to the file and write access to the directory.

For this reason, it is best for a security administrator to enable auditing for all types of object access events. For example, to track all instances where a user tries to access a file but fails, a security administrator would use the /ENABLE=ACCESS=FAILURE=ALL qualifier to the SET AUDIT command.

For object classes that support deaccess auditing (for example, the file class), once a process gains access to an object, the system does not audit subsequent access attempts to the object unless the process attempts an operation that is incompatible with the access modes previously granted. When this occurs, the system performs an additional protection check that is audited. This access window continues until the object is deaccessed (for example, the file is closed).

4.7.3. Adding Security-Auditing ACEs

Rather than audit an entire class of objects, security administrators and users with control access to an object can single out a specific object for auditing by attaching an Alarm or Audit ACE to it (see Section 3.10.2). Although you can add an auditing ACE to any file that you own or have control access to, it is best to consult your security administrator before doing so. As with object classes, the security administrator has to enable the ACL auditing category before any auditing messages are generated.

Chapter 5. Descriptions of Object Classes

This chapter describes the unique features of each class of protected object: files, volumes, devices, and so on. Each class description contains information on the following topics:

Topic

Description

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.

5.1. Capabilities

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

5.1.3. Template Profile

The capability class provides the following template profile:

Template Name

Owner UIC

Protection Code

DEFAULT

[SYSTEM]

S:U,O:U,G:U,W:U

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

5.1.4. Kinds of Auditing Performed

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

5.1.5. Permanence of the Object

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

The common event flag cluster class supports the following 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.

5.2.3. Template Profile

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

DEFAULT

[0,0]

S:AD,O:AD,G:A,W

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

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. Virtual terminals are considered LOCAL devices. They can be created over the network or on the local system.

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 VSI OpenVMS System Manager's Manual and the VSI 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 device

      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

 

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

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.

    Note

    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:
    $ SET SECURITY/CLASS=DEVICE/PROTECTION=(S:RWLP,O:RWLP,G:RW,W:R) FTA0:

    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.

    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

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.

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 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 VSI 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, 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.

    Note

    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 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:
  1. 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)
  2. 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).

  3. 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.

  4. 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.

  5. 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

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

5.4.7.1. 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.

5.4.7.2. 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 SET VOLUME/NOHIGHWATER_MARKING.

5.4.7.3. 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.

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

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.

5.5.1. Naming Rules

The name of the object is a string of 1 to 44 characters. For group global sections, the name is qualified by your UIC group number.

5.5.2. Types of Access

The global section class supports the following types of access:

Read

Gives you the right to map the section for read access.

Write

Gives you the right to map the section for write access.

Execute

Gives you the right to map the section for read access. Only software running in executive or kernel mode can request this access.

Control

Gives you the right to modify the protection elements of PFN global sections and page file-backed global sections.

5.5.3. Template Profile

File-backed global sections share the security profile of the associated disk file. Whenever the profile of the backing file is modified, the global section's profile automatically changes. To modify the protection elements of file-backed global sections, you must modify the backing file instead.

The global section class provides the following template profiles. 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.

Type

Template Name

Owner UIC

Protection Code

System

DEFAULT

[0,0]

S:RWE,O:RWE,G:RWE,W:RWE

Group

DEFAULT

[0,0]

S:RWE,O:RWE,G:RWE,W:RWE

The operating system modifies the templates according to the values provided in the prot argument to $CRMPSC. The prot argument is ignored for file-backed sections.

To maintain compatibility with earlier versions of the operating system, the DEFAULT templates have protection codes allowing world access. Some applications may need a more restrictive default than the templates provide. If you do choose to restrict global section access, be aware that the more restrictive access can cause applications to fail in ways that are difficult to diagnose.

5.5.4. Privilege Requirements

The SYSGBL privilege is required to create or delete a system global section. The PFNMAP privilege is necessary to create or delete a page frame section, and the PRMGBL privilege is required to create or delete a permanent global section.

5.5.5. 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

Creation

When a page file-backed or a PFN global section is created by the Create and Map Section system service ($CRMPSC).

Access

When an existing page file-backed or a PFN global section is accessed with either $CRMPSC or the Map Global Section system service ($MGBLSC). The operating system audits access to a file-backed global section as a file access.

Deaccess

At image or process rundown when the process virtual address space is reset or deleted.

Deletion

If a process with PRMGBL privilege, PFNMAP privilege, or SYSGBL privilege (in the case of a system global section) deletes a permanent global section, the operating system audits the event through the use of privilege.

5.5.6. Permanence of the Object

A global section and its security profile need to be reset after every system boot.

5.6. Logical Name Tables

Logical name assignments are maintained in logical name tables. A logical name table can be accessible to only one process, or it can be shareable if its parent table is shareable. All shareable name tables are listed in the LNM$SYSTEM_DIRECTORY, the system directory table. It is shareable logical name tables that the operating system protects.

5.6.1. Naming Rules

The name of a logical name table is a string of 1 to 32 characters.

5.6.2. Types of Access

The logical name table class supports the following types of access:

Read

Gives you the right to look up (translate) logical names in the table

Write

Gives you the right to create and delete logical names in the table

Create

Gives you the right to create a descendant logical name table, including the right to use a subset of the dynamic memory allocated to the parent logical name table when creating the descendant logical name table

Delete

Gives you the right to delete the table

Control

Gives you the right to modify the protection elements and owner of the table

5.6.3. Template Profile

The logical name table class provides the following template profiles. 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

DEFAULT

[0,0]

S:RW,O:RW,G:R,W:R

GROUP

[0,*]

S:RWCD,O:R,G:R,W

JOB

[0,0]

S:RWCD,O:RWCD,G,W

5.6.4. Privilege Requirements

The operating system allows read and write access to the group logical name tables with GRPNAM privilege and to the system logical name table with SYSNAM privilege.

Deletion of a shared table from the system directory requires SYSNAM privilege, and deletion of a logical name from the group directory requires GRPNAM privilege. Deletion of a parent logical name table results in the deletion of all its descendant logical name tables.

Creation or deletion of an inner-mode logical name or logical name table requires SYSNAM privilege (or being in an inner mode).

5.6.5. Kinds of Auditing Performed

The following events can be audited, provided the security administrator enables auditing for the event class:

Event Audited

When Audit Occurs

Access

When translating a name, when creating a name or a descendent table, or when deleting a name or a descendent table

Creation

During access to a parent table for the right to create a table or when the table itself is created

5.6.6. Permanence of the Object

A logical name table and its security profile must be reset each time the system is rebooted.

5.7. Queues

A queue is a set of jobs to be processed. In general, queues are of two types, generic or execution. No processing takes place in generic queues. Execution queues hold jobs that will execute on an execution queue when one is available. Execution queues can be batch queues, printer queues, server queues, or terminal queues.

5.7.1. Naming Rules

A queue name is a string of 1 to 31 characters, including any alphanumeric character, the dollar sign ($), or the underscore (_).

5.7.2. Types of Access

The queue class supports the following types of access:

Read

Gives you the right to see the security elements of either a queue or a job in the queue.

Submit

Gives you the right to place jobs in the queue.

Delete

Gives you the right to either delete a job in the queue or modify the elements of a job.

Manage

Gives you the right to affect any job in the queue. You can start, stop, or delete a queue and change its status and any elements that are unrelated to security.

Control

Gives you the right to modify the protection elements and owner of a queue.

Note

When a process receives read or delete access through a protection code, it can operate on only its job in the queue. However, when granted through an ACL, read and delete access allow a process to operate on all jobs in the queue.

5.7.3. Template Profile

The queue class provides the following template profile:

Template Name

Owner UIC

Protection Code

DEFAULT

[SYSTEM]

S:M,O:D,G:R,W:S

5.7.4. Privilege Requirements

You need SYSNAM and OPER privileges to stop or start the queue manager. OPER is necessary to either create and delete queues, or to change the symbiont definition.

5.7.5. Kinds of Auditing Performed

The following events can be audited, provided the security administrator enables auditing for the event class:

Event Audited

When Audit Occurs

Access

When a job is submitted to the queue and when either a job or queue is modified.

Creation

When a queue is initialized.

Deletion

When a process deletes a job from the queue or when the queue itself is deleted. (To enable auditing for queue deletions, enable auditing for manage [M] access to the queue.)

If access auditing is enabled for both files and queues, one queue operation can generate a number of auditing messages because, within a single operation, the operating system performs several access checks. For example, before a job is executed on a print queue, the system checks to see if you have read access to the file, and it checks for read access again before printing the file.

5.7.6. Permanence of the Object

Queues are permanent objects. They are stored in the system queue database together with their security profiles.

5.8. Resource Domains

Processes that access shared resources can coordinate access using the services of the lock manager. These services allow processes to associate a name with a resource, such as a file or a data structure, to arbitrate access to that resource, and to exchange limited information through a lock value block. The namespaces that catalog resources on which locks can be taken are called resource domains.

A process must become a member of a resource domain to take and release locks and to read and write value blocks associated with resources in that resource domain. A process implicitly joins the system and group domains, but it explicitly joins other domains through a call to the $SET_RESOURCE_DOMAIN system service. Access to all locks and value blocks within a domain is controlled by access to the domain itself.

5.8.1. Naming Rules

A resource domain is identified to $SET_RESOURCE_DOMAIN by a longword binary value. However, the name of the resource domain object is a string containing the resource number interpreted in octal surrounded by brackets [] or angle brackets <>. Alternatively, the name of the resource domain object can be expressed as an identifier enclosed in brackets or angle brackets. The identifier must translate to a UIC value; the group field of the UIC is used as the resource domain number.

5.8.2. Types of Access

The resource domain class supports the following types of access:

Read

Gives you the right to read lock value blocks in the domain, including the right to use the $GETLKI system service to retrieve it

Write

Gives you the right to write to lock value blocks in the domain

Lock

Gives you the right to take locks using $ENQ, release locks using $DEQ, and obtain information about the lock database using $GETLKI

Control

Gives you the right to modify the protection elements of a resource domain

5.8.3. Template Profile

The resource domain class provides the following template profile. The template assigns an owner UIC of [ n,*] where n is the resource domain's number.

Template Name

Owner UIC

Protection Code

DEFAULT

[ n,*]

S:RWL,O:RWL,G:RWL,W

5.8.4. Privilege Requirements

The SYSLCK privilege allows lock access to the system resource domain (Domain 0).

5.8.5. Kinds of Auditing Performed

The following events can be audited, provided the security administrator enables auditing for the event class:

Event Audited

When Audit Occurs

Access

When a process calls $SET_RESOURCE_DOMAIN or $ENQ to join a domain

Creation

The first time a process joins the resource domain

Deaccess

When a process called $SET_RESOURCE_DOMAIN or at image or process rundown

5.8.6. Permanence of the Object

Both the resource domain and its security elements are saved in SYS$SYSTEM:VMS$OBJECTS.DAT.

5.9. Security Classes

The security class is the parent of all classes of protected objects. It protects the template profiles associated with the various object classes. Each object in the security class holds the following information:
  • An object name

  • A security profile for new objects of the class

  • One or more template profiles

  • A set of access names

  • Auditing controls

Chapter 8 discusses how to manage objects in the security class.

5.9.1. Naming Rules

The security class has the following members:

CAPABILITY

COMMON_EVENT_CLUSTER

DEVICE

FILE

GROUP_GLOBAL_SECTION

LOGICAL_NAME_TABLE

QUEUE

RESOURCE_DOMAIN

SECURITY_CLASS

SYSTEM_GLOBAL_SECTION

VOLUME

5.9.2. Types of Access

Security class objects support the following types of access:

Read

Gives you the right to read a template profile. Template profiles contain the security elements assigned to new objects.

Write

Gives you the right to modify the values of a template profile.

Control

Gives you the right to modify the security profile of a security class object. Control access implies read and write access.

5.9.3. Template Profile

The security class object provides the following template profile:

Template Name

Owner UIC

Protection Code

DEFAULT

[SYSTEM]

S:RW,O:RW,G:R,W:R

5.9.4. Kinds of Auditing Performed

The following events can be audited, provided the security administrator enables auditing for the event class:

Event Audited

When Audit Occurs

Access

When a process enters the DCL command SET SECURITY or SHOW SECURITY with the /CLASS=SECURITY_CLASS qualifier or when it uses the name SECURITY_CLASS in a call to the system service $SET_SECURITY or $GET_SECURITY

5.9.5. Permanence of the Object

The security profiles of the security class object and all its members are stored in the security object database.

5.10. Volumes

A volume object is one or more ODS-2 disk volumes. The object consists of multiple volumes when they are part of a bound volume set. Although you might have access to the directories and files on the volume, you cannot access them if you do not have access to the volume itself.

For access information on tapes and foreign volumes, see the VSI OpenVMS System Manager's Manual and the Mount utility documentation in the VSI OpenVMS System Management Utilities Reference Manual.

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:

Read

Gives you the right to examine file names and print and copy files on a volume.

Write

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.

Create

Gives you the right to create files on a disk volume and to subsequently modify them. Create access also requires read and write access.

Delete

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.

Control

Gives you the right to change the protection and ownership elements of the volume.

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.

Template Name

Owner UIC

Protection Code

DEFAULT

[0,0]

S:RWCD,O:RWCD,G:RWCD,W:RWCD

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.

Event Audited

When Audit Occurs

Access

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 [000000]SECURITY.SYS.

Chapter 6. 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 following topics:
  • 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

VSI 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 implement them.

6.1. Role of a Security Administrator

Your role as security administrator 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 Section 6.2.

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 its requirements.

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 system environments.

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 needs.

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

Security Area

Site Requirements

Passwords

Schedule for password changes.

Process for controlling minimum password length and expiration periods.

Schedule for system password changes.

Accounts

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 list current.

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 computer room

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 information.

  • Locking disks and file cabinets.

  • Keeping diskettes inaccessible in or near workstations.

  • Keeping keys out of open view.

Dialup numbers

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

Communications

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 VSI OpenVMS System Management Utilities Reference Manual. The AUTOGEN command procedure, which you use to modify the system parameters file, is described in the VSI OpenVMS System Manager's Manual and the VSI OpenVMS System Management Utilities Reference Manual. Many DCL commands are also important security tools. DCL commands are described in the VSI OpenVMS DCL Dictionary.

6.4. Account Requirements for a Security Administrator

You need an account with privileges to perform the tasks of a security administrator.

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 VSI 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.

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 Account
$ 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
_UAF> /PRIVILEGES=(AUDIT,SECURITY,READALL)                   3
identifier for value:[000001,000100] added to RIGHTSLIST.DAT
UAF>
Notice the following:

1

The requirement that the automatic password generator be used to change passwords.

2

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.

3

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.

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 available?

  • Which terminals can be used for logging in, and where are they located?

  • 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 details.

  • 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 interactive?

  • 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 acceptable practice.

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:
  1. Set up the restricted account USER_LOG as follows:
    UAF> ADD USER_LOG /FLAGS=(RESTRICTED,DISMAIL,DISNEWMAIL)-
    _UAF> /LGICMD=SYS$SYSROOT:[USER_LOG]SESSIONLOG-
    _UAF> DEV=SYS$SYSROOT: /DIR=[USER_LOG]-
    _UAF> /NONETWORK /NOBATCH /UIC=[200,256]
  2. The SESSIONLOG.COM command procedure enables logging of the terminal session:
    $ ! 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
    $ LOGOUT
  3. 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 -
    _UAF> /LGICMD=SYS$SYSROOT:[USER_LOG]CHECKLOG

    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.

  4. 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 example:
    UAF> MODIFY SMITH/FLAGS=RESTRICTED/NOLOCAL/NODIALUP/NOBATCH -
         /NONETWORK/LGICMD=SYS$SYSROOT:[USER_LOG]CHECKLOG
  5. 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 Section 13.3.2.
    $ ! 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."
    $ LOGOUT

    $ !
    $ ! 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.
    $ !
    $ OK:
    $ SET CONTROL_Y
    $ IF F$SEARCH ("LOGIN.COM") .EQS. "" THEN EXIT
    $ @LOGIN

6.7. Ongoing Tasks to Maintain a Secure System

Maintaining a secure system requires continuous surveillance. The following ongoing tasks are important to you in your role as security administrator:
  • Use the MONITOR IO report to develop a familiarity with the normal amounts of I/O on your system at various times. Watch for abnormal changes.

  • Keep informed of the images installed on your system. Use the Install utility (INSTALL) to look for unexpected additions. When monitoring the known file list, compare the current list with a valid hardcopy listing.

  • Use the AUTHORIZE command SHOW on a regular basis to check for unauthorized user names.

  • Use the AUTHORIZE command SHOW/PROXY regularly to quickly recognize all proxy access that you have authorized. Watch for unexpected additions. Remove any remote users who no longer require access. Institute regular communications with system managers at remote nodes.

  • Apply the Accounting utility (ACCOUNTING) on a regular basis to give you a basis of normal amounts of processing time. Watch for unexplained changes.

  • Regularly check the accounting report produced by ACCOUNTING for known user names, unknown user names, and appropriate hours of system use.

  • Develop sufficient familiarity with your system's workload so that you notice normal (as well as abnormal) processing activity occurring at unusual hours.

  • Monitor device allocations routinely with the DCL command SHOW DEVICE so that you immediately notice any that are unexpected.

  • Become familiar with the recurring types of batch jobs that run on the batch queues and what times they are most likely to run.

  • Monitor the protection and ownership of critical files with the DIRECTORY/SECURITY command. Watch for unexplained changes in each.

  • Maintain familiarity with the rights list. Keep current listings so that you can recognize identifiers that have been added or new holders of the current identifiers.

  • Remove identifiers that are not in use. Keep the rights list current.

  • Regularly review the templates that you use to set up UAF records. Make any necessary changes.

  • Use the security-auditing features described in Chapter 10.

  • Apply the Audit Analysis utility (ANALYZE/AUDIT) regularly to detect abnormal auditing activity.

  • When you allow new users to change their initial passwords, assign passwords that users will want to change or use the password generator. Check back to see if you can log in with the password you originally assigned. Where necessary, follow up with the user to determine why the change did not occur as requested.

  • Try searching unprotected user files for passwords embedded in network access control strings. The password will precede the 3-character terminator ("::). Also search for the noun password, and see if any passwords are revealed nearby.

  • Check that your users are logging out properly. Make physical checks at the end of normal business hours.

  • Check that your users have appropriate default protections in place.

  • Keep informed about your inventory of magnetic tapes, disks, and program listings. Routinely check that inventory for possible indications that physical security has degraded.

  • Keep your office and all important listings locked up.

Chapter 7. Managing System Access

This chapter explains how you give users access to a system by assigning user accounts and passwords. Descriptions are based on the security needs of a commercial installation with average security needs, where accounts require protection. Descriptions of above-average security needs are also noted. Refer to Chapter 8 for information on controlling access to system data and resources. See Chapter 6 and Chapter 10 for information on auditing user actions.

The Authorize utility (AUTHORIZE) is the primary tool for establishing accounts and passwords. See the VSI OpenVMS System Management Utilities Reference Manual, Volume 1: A-L for a description of the utility.

7.1. Defining Times and Conditions for System Access

The level of system access a user enjoys depends on your site requirements, that user's role in the organization, and your management of his or her account. A site with low security requirements and plenty of system resources may allow access at any time of day whereas a site with moderate security requirements may limit logins to daytime hours and permit dialup or network connections only to a subset of users.

Using the Authorize utility, you control when and how users can access the system. Table 7.1 identifies the applicable qualifiers.
Table 7.1. Authorize Qualifiers Controlling Login Times and Conditions

Categories

Qualifier

Description

Time of day

/ACCESS

By default, a user has full access every day. By specifying an access time, you prevent access at all other times. Identify hours on primary days with the keyword PRIMARY; identify hours on secondary days with the keyword SECONDARY.

/DIALUP

Specifies hours of access permitted for dialup logins.

/LOCAL

Specifies hours of access for interactive logins from local terminals.

Days of week

/PRIMEDAYS

Defines the primary and secondary days of the week for logging in.

Mode of operation

/BATCH

Specifies the hours of access permitted for batch jobs.

/INTERACTIVE

Specifies the hours of access for interactive logins.

/NETWORK

Specifies the hours of access permitted for network batch jobs.

/REMOTE

Specifies hours during which access is permitted for interactive logins from network remote terminals (with the DCL command SET HOST).

Allocation of resources

/DEVICE

Specifies the name of the user's default device at login.

/DIRECTORY

Specifies the name of the user's default directory at login.

Validity of account

/EXPIRATION

Specifies the expiration date and time of the account.

/FLAGS=DISUSER

Disables the account so the user cannot log in.

External authentication

/FLAGS=EXTAUTH

Specifies that the user is externally authenticated.

7.1.1. Restricting Work Times

AUTHORIZE qualifiers let you restrict system use to certain days of the week and certain periods of the day. Restricting work times is useful to better balance the workload on your system. Restricting access to accounts is also an effective way of preventing unauthorized use of the system outside of normal working hours.

Define primary and secondary days of the week with the /PRIMEDAYS qualifier, or conform to the default where primary days are Monday through Friday and secondary days are Saturday and Sunday. For example, to modify the defaults for a user who works Tuesday through Saturday, you would specify the /PRIMEDAYS qualifier as follows:
/PRIMEDAYS=(NOMONDAY,TUESDAY,WEDNESDAY,THURSDAY,FRIDAY,SATURDAY,NOSUNDAY)

Occasionally an operational change occurs that conflicts with the normal day assignments at your site, such as a holiday falling on a primary day. To override the normal day assignment, use the DCL command SET DAY, and specify the day-type interpretation you want for the current day. This requires OPER privilege. Note that this change applies to all logged-in users, as well as those who will log in during the day. If users who are currently logged in are unauthorized for the day-type once it changes, they are logged out of the system at the next hour. (The job controller enforces time restrictions on an hourly basis.)

Decide which types of login access should be restricted to certain hours. The login access qualifiers are: /LOCAL, /REMOTE, /DIALUP, /INTERACTIVE, /BATCH, and /NETWORK. However, if your site applies one set of primary and secondary hours for all types of logins, you can specify the /ACCESS qualifier, which applies to all modes of access.

The following example shows how to apply the /BATCH qualifier to a user's account to disable the user from running batch jobs during normal working hours:
/NOBATCH=(PRIMARY, 9-17)

This specification permits the user to run batch jobs only during the hours of 6:00 p.m. through 8:59 a.m. on primary days but all day on secondary days.

7.1.2. Restricting Modes of Operation

The following concerns might cause you to prohibit network access for some of your users:
  • The user has data that should be accessed only through the local node.

  • Penetration attempts are more likely to occur over a network because of the increased anonymity of the connection. (This concern is also relevant to dialup connections.)

Use the AUTHORIZE qualifier /NONETWORK to prevent specific users from having network access, as shown in the following example:
UAF> ADD JSMITH /NONETWORK, ...

Any of the AUTHORIZE access mode qualifiers (/LOCAL, /REMOTE, /DIALUP, /INTERACTIVE, /BATCH, or /NETWORK) can be negated in this manner to restrict access to the system.

7.1.3. Restricting Account Duration

It is good practice to set an account expiration time that matches the maximum length of time you expect the user to require access. When the expiration time arrives, the system automatically prohibits access to the account. You must still remove the UAF record and delete the user's files.

Use of the /EXPIRATION qualifier also forces you to periodically review accounts and reauthorize only those that are necessary.

To set the account expiration time, use the AUTHORIZE qualifier /EXPIRATION in the user's UAF record. For example, the following qualifier specifies that the user's account will expire on the 30th of December 2008:
/EXPIRATION=30-DEC-2008

7.1.4. Disabling Accounts

You may want to severely restrict the use of certain accounts. For example, you may want to disable specific accounts used only periodically, such as the SYSTEST and FIELD accounts, to limit possible misuse of these accounts. Disable the accounts with the /FLAGS=DISUSER qualifier. Temporarily enable the accounts with the /FLAGS=NODISUSER qualifier when needed.

7.1.5. Restricting Disk Volumes

Identify the user's default device and directory in the UAF record with the AUTHORIZE qualifiers /DEVICE and /DIRECTORY. You can limit the number of blocks available to the user on that disk (and any other disk) through the disk quota feature of the System Management utility (SYSMAN), as described in the VSI OpenVMS System Management Utilities Reference Manual, Volume 1: A-L.

The volume protection in place on other disks controls how much access a user can obtain to the disks. The user's privileges, which can be extended or limited through the AUTHORIZE qualifier /PRIVILEGES, also influence the access available (see Section 8.7).

7.1.6. Marking Accounts for External Authentication

Mark a user account in the UAF record with the AUTHORIZE qualifier /FLAGS=EXTAUTH to allow the user to be externally authenticated (see Section 7.4 for more information).

7.2. Assigning Appropriate Accounts to Users

The type of system access a user holds largely depends on his or her need for system resources and your site's security requirements. This section describes the types of user accounts that are available on OpenVMS systems and explains why one type of account may be preferable to another. For a step-by-step description of adding user accounts, refer to the VSI OpenVMS System Manager's Manual.

7.2.1. Types of System Accounts

There are two major types of accounts:
  • Interactive accounts have access to system software. Usually, such an account is considered an individual account.

  • Limited-access accounts provide controlled login to the system and, in some cases, controlled access to user software. Limited-access accounts ensure that the system and process login command procedures, as well as any command procedures they call, are executed. There are two types of limited accounts: captive and restricted. Guest, proxy, and automatic login accounts are forms of captive and restricted accounts. DECwindows software does not currently support captive or restricted logins in the traditional sense. Once a user is logged in and creates a DECterm window, however, the traditional environment of a captive or restricted account applies.

Both interactive and limited-access accounts can be privileged accounts, and can be externally authenticated, as Section 7.2.2 describes.

The following table shows the kind of account to create based on the task a user performs:

If Users Need to...

Type of Account to Create

Perform work of a general nature, such as program development or text editing

Interactive

Perform routine computer tasks requiring limited activities

Captive

Run batch operations during unsupervised periods

Captive

Run applications programs with confidential information

Captive

Use network applications like MAIL

Restricted

Access resources on your system from a remote system (in a limited manner)

Captive or restricted

Use network proxy accounts

Restricted

Use authentication systems like smart cards

Restricted

Use accounts created as part of a layered product installation

Restricted

Perform privileged operations

Interactive, restricted, or captive

Access resources from a remote system without a password

Captive

Automatically log in to an application terminal

Captive or restricted

Log in at the OpenVMS login prompt using their external user IDs and passwords

Externally authenticated

You may develop one or more templates that work for many of your users. However, do not oversimplify the process of account creation to the point that you simply apply a template. The danger in relying solely on templates is that you might overlook special considerations that apply to individual users, thereby forfeiting important controls that only you can exercise.

Examine templates regularly to be sure they are valid and reflect the way you want your operations to proceed. Templates become obsolete rapidly.

7.2.1.1. Interactive Account Example

Example 7.1 shows how to create an interactive user account with moderate restrictions, typical of an account at a commercial site where security is a concern and the average user has limited access. Notice the following:
Example 7.1. Creating a Typical Interactive User Account
$ SET DEFAULT SYS$SYSTEM
$ RUN AUTHORIZE
UAF> ADD RDOGWOOD /PASSWORD=TRALAYAM/UIC=[231,010] -  1
_UAF> /DEVICE=BOTANYDEV/DIRECTORY=[RDOGWOOD] -
_UAF> /OWNER="Robert Dogwood"/ACCOUNT=BOTNYDPT -
_UAF> /FLAGS=(GENPWD)/PWDMINIMUM=6 -                  2
_UAF> /EXPIRATION=15-JUNE-2003/PWDLIFETIME=90-        3
_UAF> /PRIMEDAYS=(MON,TUES,WED,THURS,FRI,SAT,NOSUN) - 4
_UAF> /NOACCESS=(PRIMARY,23-6,SECONDARY)/NODIALUP     5
identifier for value:[000231,000010] added to RIGHTSLIST.DAT
UAF>

1

Only one password is required.

2

The password has a minimum length of 6 characters.

3

The user's password is valid for 90 days, a much longer lifetime than the manager's password shown in Example 6.1.

4

The user is allowed access during the week and on Saturdays.

5

During those six days, the user has access during a 15-hour period.

7.2.1.2. Limited-Account Example

Example 7.2 shows how to create an applications production account where the user is highly restricted. This account is designed to perform two functions: list the grades at State University, and produce mailings to each student's home.

In the example, any value not specified defaults to the value provided by the default record in SYSUAF.DAT.

Example 7.2. Creating a Limited-Access Account
$ SET DEFAULT SYS$SYSTEM
$ RUN AUTHORIZE
UAF> ADD REPGRADES /DEVICE=ADMINDEV/DIRECTORY=[REPGRADES] -
_UAF> /FLAGS=(CAPTIVE,DISWELCOME,DISNEWMAIL,DISMAIL,DEFCLI) - 1
_UAF> /PASSWORD=GROBWACH/UIC=[777,031] -                      2
_UAF> /OWNER="Campus Admin"/ACCOUNT=ADMIN -
_UAF> /LOCAL=(PRIMARY,8-17)/PRIMEDAYS=(MON,TUES,WED,THU, -    3
_UAF> FRI,NOSAT,NOSUN) -
_UAF> /NONETWORK/NOREMOTE/NODIALUP -                          4
_UAF> /LGICMD=GRADES  5/CLITABLES=GRADES_TABLES -       6
  .
  .
  .
user record successfully added
identifier for value:[000777,000031] added to RIGHTSLIST.DAT
Notice the following:

1

Account users do not see the normal system welcome message. The account may not receive mail. It is restricted to running under control of its login command procedure and the default command interpreter (DCL).

2

The user who initiates the login must specify the password, GROBWACH. (Most likely only the security administrator will change the password.)

3

When the job is run through a local login, it is restricted to the hours of 8 a.m. through 5:59 p.m., Monday through Friday. (Notice that only batch and local logins are allowed, and batch mode does not have time restrictions.)

4

The job may not be run over dialup lines or as a remote job. The account also denies network access.

5

The process runs under the control of a special login command procedure (GRADES.COM), which presumably provides the operator with a menu of functions.

6

The process is restricted to the commands defined in the CLI table GRADES_TABLES.

7.2.2. Privileged Accounts

Privileges determine the functions users are authorized to perform on the system. Any account with privileges beyond TMPMBX and NETMBX is considered privileged. Such an account can be interactive, restricted, or captive.

Because abuse of privileged accounts can result in serious losses, consider imposing special controls on accounts with the most powerful privileges as follows:
  • Limit access to the account. For example, you can prohibit dialup or network access with the /NODIALUP or /NONETWORK qualifier to discourage outsiders from attempting break-ins from remote locations.

  • Impose security alarms to detect use of the privileges pertaining to file protection: BYPASS, SYSPRV, READALL, and GRPPRV. For information about setting up and monitoring security alarms, see Chapter 10.

For all but the SYSTEM account, also add the following restrictions:
  • Use the /PRIMEDAYS and /NOACCESS qualifiers to restrict the time of day or days of the week that logins can be performed. Select periods of time that can be monitored for appropriate use.

  • Disable the account when not in use with the AUTHORIZE qualifier /FLAGS=DISUSER.

  • Use a captive login command procedure for additional validation. Captive login command procedures are described in Section 7.2.4.

Naturally, you need to set controls on the SYSTEM account. The most secure practice is to disable it for all but batch access and perform system management through individual privileged user accounts, which provide accountability.

Special-Purpose Privileged Captive Accounts

Because the safety of a captive account depends on the integrity of its command procedures, it is unadvisable to set up privileged captive accounts for untrusted users. However, there are some situations that require privilege, and it is safer to perform specific sensitive functions through captive privileged accounts than through general purpose privileged accounts. For example, users who perform backup operations require the READALL privilege. By making the account that performs backups captive, you can ensure that the procedures are carried out according to your system's backup policy.

See Section 7.2.4 for guidelines for setting up captive accounts.

7.2.3. Interactive Accounts

Interactive accounts are very common in environments with low to moderate security requirements. They are well suited to work of a general nature, such as program development or text editing. The VSI OpenVMS System Manager's Manual explains the procedure for setting up this type of account. Section 7.2.1.1 provides an example.

7.2.4. Captive Accounts

A captive account limits the activities of the user and, when properly administered, denies the user access to the DCL command level. You can set up the account to limit the user to running under the complete control of a specific program or the captive login command procedure.

The primary feature of the captive account is its login command procedure. This type of account ensures that the system login command procedure (SYLOGIN.COM) and the process login command procedure (specified by the /LGICMD qualifier in SYSUAF.DAT), as well as any command procedures they call, are executed. A user cannot specify any of the qualifiers shown in Table 7.2 to modify the captive command procedures when logging in.

Once logged in to a captive account, a user cannot escape to the DCL command level through the Ctrl/Y sequence, the SPAWN command, or the INQUIRE command. Because the DISCTLY flag in the UAF record is turned on, any use of Ctrl/Y fails. If unhandled errors or attempted interrupts occur, a system error message is generated, and the session is logged out. Unless the SPAWN command carries the /TRUSTED qualifier, it is ineffective within a captive account. SPAWN is also disabled from MAIL and the DEC Text Processing Utility (DECTPU) (as a built-in procedure). The INQUIRE command is also disabled to prevent the possible execution of user-specified lexical functions.
Table 7.2. Login Qualifiers Not Allowed by Captive Accounts

Qualifier

Description

/CLI

Specifies the name of an alternate command language interpreter

/COMMAND

Overrides the default login command procedure

/NOCOMMAND

Disables execution of the default login command procedure

/DISK

Requests an alternate default disk

/TABLES

Specifies the name of an alternate CLI table

7.2.4.1. Setting Up Captive Accounts

You define a captive account with AUTHORIZE by including the following qualifier when creating the account:
/FLAGS=(CAPTIVE)
A captive account also requires the qualifiers described in Table 7.3.
Table 7.3. Qualifiers Required to Define Captive Accounts

Qualifier

Action

/LGICMD

Identifies the captive account login command procedure and overrides the default login command procedure (LOGIN.COM in the user's default directory).

/UIC

Assigns a unique UIC group. Use the following form of the AUTHORIZE command SHOW to verify the uniqueness of the UIC group:
SHOW [groupuic,*]
By keeping the account in a separate group, you can ensure that the captive account users can access only world-accessible files and files owned by the captive account. It ensures that the account is not a member of the system group (that is, has a group value less than or equal to 10 8, unless modified by the system parameter MAXSYSGROUP).

/NOPASSWORD or /FLAGS=LOCKPWD

Sets up the password. With a captive account, either require no password, or lock the password so that only the security administrator can change it. Locked passwords are generally preferable to open captive accounts (those with no password). If you assign a locked password, give that password to all users of the captive account.

/PRCLM

Sets the subprocess limit to 0, thus preventing the user from spawning out of the account. (Verify that the system parameter PQL_MPRCLM—the minimum subprocess limit—is set to 0.)

In addition to the required settings, you may want to specify additional characteristics for the account:
  • You may want to disable the welcome announcement and electronic mail for the captive account. This is done by setting the DISWELCOME, DISMAIL, and DISNEWMAIL login flags.

  • You may want to allow only interactive use of the account from a local terminal. Include the qualifiers /NODIALUP, /NOREMOTE, /NOBATCH, and /NONETWORK when establishing the account.

  • Your application may have special requirements. You may need to impose additional AUTHORIZE qualifiers on the account, such as /NODIALUP, to restrict modes of operation. Consider imposing restrictions for the periods of the day and days of the week when the process can run.

  • You can define a special set of DCL tables by using the /CLITABLES qualifier, or you can emulate DCL through the use of a DCL command procedure. It is more efficient to define DCL tables than to resort to a DCL command procedure to emulate DCL. See the description of the Command Definition utility (CDU) in the VSI OpenVMS System Management Utilities Reference Manual, Volume 1: A-L for help when defining the DCL tables. Be aware that the DCL tables defined by the /CLITABLES qualifier are not used in network jobs, such as those using the TASK object.

  • You can grant privileges, although you rarely need to grant any privilege other than TMPMBX to a captive account.

  • You can limit the disk quota for the captive account to the amount needed.

7.2.4.2. Guidelines for Captive Command Procedures

When writing captive command procedures for your site, be sure to observe the following guidelines:
  • Use the DCL command READ/PROMPT in command procedures. For example, to request the user to enter the date, enter the following command in the command procedure:
    READ/PROMPT="Enter date: " SYS$COMMAND DATE
  • Avoid use of the INQUIRE command in a captive command procedure. It produces an error that, if unhandled by a previous ON declaration, results in deletion of the process.

  • When user input is required, never execute it directly. First compare it to what is expected, and screen for illegal characters such as apostrophe ('), at sign (@), dollar sign ($), quotation mark ("), ampersand (&), or hyphen (-).

  • Avoid any use of the construction ’x, where x contains a string entered by the user. Never permit a restricted command procedure to attempt an evaluation of a symbol that the user enters. Use of lexical functions could break the command procedure.

  • Avoid executing a line in a captive command procedure that contains the characters @TT:.

  • Put Audit ACEs on the captive command procedure and its home directory to detect any modification of the file. See Section 3.10.2 for more information on Audit ACEs.

  • If the captive account user is allowed to create or perform other operations on files, make certain that write access to the login command procedure and its directory is denied. (The user does need execute access.)

    If the function of the command procedure requires text preparation, you may need to give users access to a text editor. Use caution, however. Editors such as TECO or DECTPU can be dangerous because users can manipulate files and exit from the editor to the DCL interface. When designing this environment, remember that most text editors are capable of reading and writing files (within the access rights of the account). Provide an editor that gives users the tools they require but does not allow them to escape from the captive environment.

Example 7.3 and Example 7.4 provide sample command procedures for privileged and unprivileged accounts.
Example 7.3. Sample Captive Procedure for Privileged Accounts
$ if f$mode() .nes. "INTERACTIVE" then $logout
$ term = f$logical("SYS$COMMAND")
$ if f$locate("_T", term) .eq. 0 then $goto allow
$ if f$locate("_OP",term) .ne. 0 then $logout $allow:
$ set control=(y,t)

Example 7.4. Sample Captive Command Procedure for Unprivileged Accounts
$ deassign sys$input
$ previous_sysinput == f$logical("SYS$INPUT")
$ on error then goto next_command
$ on control_y then goto next_command
$ set control=(y,t)
$
$next_command:
$ on error then goto next_command
$ on control_y then goto next_command
$
$ if previous_sysinput .nes. f$logical("SYS$INPUT") then deassign sys$input
$ read/end=next_command/prompt="$ " sys$command command
$ command == f$edit(command,"UPCASE,TRIM,COMPRESS")
$ if f$length(command) .eq. 0 then goto next_command
$
$ delete = "delete"
$ delete/symbol/local/all
$ if f$locate("@",command) .ne. f$length(command) then goto illegal_command
$ if f$locate("=",command) .ne. f$length(command) then goto illegal_command
$ if f$locate("F$",command) .ne. f$length(command) then goto illegal_command
$ verb = f$element(0," ",command)
$
$ if verb .eqs. "LOGOUT" then goto do_logout
$ if verb .eqs. "HELP" then goto do_help
$
$ write sys$output "%CAPTIVE-W-IVVERB, unrecognized command \",verb,"\"
$ goto next_command
$
$illegal_command:
$ write sys$output "%CAPTIVE-W-ILLEGAL, bad characters in command line"
$ goto next_command
$
$do_logout:
$ logout
$ goto next_command
$
$do_help:
$ define sys$input sys$command
$ help
$ goto next_command

7.2.5. Restricted Accounts

Certain limited-access accounts require a less restrictive environment than captive accounts. Accounts under which network objects run, for example, require temporary access to DCL. Such accounts must be set up as restricted accounts, not captive accounts. Restricted accounts are indistinguishable from regular accounts once the login sequence finishes. The purpose behind restricted accounts is to ensure a trusted login wherein SYLOGIN, LOGIN, and their descendants execute completely.

If the restricted flag is set, it is recommended that the LOGIN.COM is not user-writable or the user cannot modify it and bypass the login procedure. It is also expected that the LOGIN.COM has error checking and error handling in place using the various error controls such as the $ SET NOON or $ ON ERROR THEN LOGOUT.

Note

The purpose of the RESTRICTED flag is to ensure that the user cannot bypass parts of the login procedures. It is not intended to invoke a mechanism by which login procedures containing bugs cause a logout.

Define a restricted account with the Authorize utility by including the following qualifier when creating the account:
/FLAGS=(RESTRICTED)

This flag ensures that the account is noted as restricted. A restricted account provides the same features as those listed for a captive account in Section 7.2.4 except that restricted accounts allow the user access to the DCL command level following the execution of the system and process login command procedures.

Sometimes it is appropriate to allow the user to enter the Ctrl/Y key sequence after the command procedure starts. For example:
  • You may want to provide users with a Ctrl/Y feature at points during the execution of the restricted login command procedure. Include ON CONTROL_Y commands in the procedure where you want to test for the Ctrl/Y features, as shown in Example 7.4.

  • You may have a restricted command procedure that ultimately turns control over to the user. For example, consider a SYLOGIN.COM command procedure that performs additional security validation; its execution should be guaranteed to ensure its effectiveness. However, once SYLOGIN.COM has done its job, control can be passed to the user. To do this, mark the account as restricted, and enter the DCL command SET CONTROL=Y when you are ready to release control to the user.

7.2.6. Automatic Login Accounts

To force individuals at specific terminals to log in to an application program, create a separate captive account for the application. Then set up automatic logins to the new account for the desired users using the System Management utility (SYSMAN).

Once you set up a terminal for automatic login, it can be used only for the designated account. This is most useful for applications terminals used by people who may be unfamiliar with computers.

The automatic login feature suppresses the user name prompt. All other login features (system password, primary and secondary passwords, and messages) function normally, if enabled.

Passwords are optional. If you want the account to be open to all users where the terminals are located, eliminate the password. When no password is required, the user has no data to enter at login. The operating system logs the terminal in automatically in response to the Break key or the Return key and immediately enters the application if the account is under the control of a captive login command procedure.

The automatic login file (ALF) lists the terminals and the users who are authorized to access the application account. However, automatic login accounts are potentially accessible from terminals and sources other than the terminals listed in the ALF file and, therefore, require protection, especially if they have no password. Use the following precautions:
  • Restrict network and dialup access, as appropriate, with the AUTHORIZE qualifiers /NODIALUP, /NONETWORK, and /NOREMOTE.

  • Set the AUTOLOGIN flag in the account's UAF record. This flag makes the account available only by autologin, batch, and network proxy.

7.2.7. Guest Accounts

Guest accounts are forms of captive or restricted accounts that allow multiple remote users access to resources on your system through a common account. For example, users across the network may need access to your system to report problems or to read corporate memos.

VSI does not recommend the practice of setting up guest accounts. Guest accounts, however unprivileged, offer malicious users a chance to compromise your system security. Most needs for a guest account can be handled by special proxy login accounts, which should also be limited-access accounts.

If you still need a guest account, take the following steps to make the account secure:
  • Use an obscure password for the guest account. Change the password frequently. Never use easily guessed account name and password combinations such as GUEST/GUEST or USER/USER.

  • Maintain a list of people allowed to use the account. (Changing the password regularly helps you keep this list current.)

  • Set up the guest account in a separate UIC group. Make sure that the account is not a member of the system group.

  • Place the default login command procedure in the directory SYS$MANAGER by using the AUTHORIZE command MODIFY, as follows:
    MODIFY guest-account/LGICMD=SYS$MANAGER:filename.COM
  • Make the guest account restricted or captive by setting the AUTHORIZE qualifiers /FLAGS=RESTRICTED or /FLAGS=CAPTIVE, respectively.

  • If the guest account is set up as a restricted account, limit the number of subprocesses that the account can create to 0 using the AUTHORIZE qualifier /PRCLM=0. (Ensure that the system parameter PQL_MPRCLM is also set to 0.)

  • Assign the guest account only TMPMBX privilege.

  • To handle error conditions, include the following commands in the default login command procedure:
    SET ON SET NOCONTROLY ON ERROR THEN LOGOUT/BRIEF
  • If the system has LOGOUT defined as a global symbol and points to a command procedure (enter the DCL command SHOW SYMBOL LOGOUT to confirm this), include the following DCL command in the default login command procedure for the account:
    DELETE/SYMBOL LOGOUT/GLOBAL

    This command eliminates the possibility that the user could break the restricted account at logout time by pressing Ctrl/Y.

  • To prevent outsiders from misusing your system resources through the submission of batch jobs under the guest account, include the AUTHORIZE qualifier /NOBATCH when you create the account.

  • Limit the disk quota for the guest account UIC to the amount needed.

  • Do not allow the DCL command INQUIRE to appear in any of the command procedures.

7.2.8. Proxy Accounts

Generally, proxy login accounts should be set up as restricted accounts. Proxy login accounts permit remote users to access a local account without specifying a password. Section 13.3.3 describes proxy login accounts. Note that many recommendations are the same as those for restricted accounts.

7.2.9. Externally Authenticated Accounts

Externally authenticated accounts are those that are marked with the EXTAUTH flag in the user's SYSUAF record. This enables these users to log in at the OpenVMS login prompt using their external user IDs and passwords. See Section 7.4 for more information on external authentication.

7.3. Using Passwords to Control System Access

A site needing average security protection always requires use of passwords. Sites with more security needs frequently impose a generated password scheme (see Section 7.3.2.4) and possibly system passwords as well.

This section describes password management.

7.3.1. Types of Passwords

With the exception of an automatic login account, all users must have at least one password to log in. Sites with moderate or high security requirements may impose additional passwords (see Table 3.2).

Externally authenticated users enter their external password at the OpenVMS password prompt. See Section 7.4 for more information.

This section explains how to assign passwords using DCL and AUTHORIZE commands.

7.3.1.1. Primary Passwords

When you open an account for a new user with AUTHORIZE, you must give the user a user name and an initial password. When you assign temporary initial passwords, observe all guidelines recommended in Section 3.8. Avoid any obvious pattern when you assign passwords. You may want to use the automatic password generator.

To use the automatic password generator while using AUTHORIZE to open an account, add the /GENERATE_PASSWORD qualifier to either the ADD or the COPY command. The system responds by offering you a list of automatically generated password choices. Select one of these passwords, and continue setting up the account.

Note

There are restrictions on using the /GENERATE_PASSWORD qualifier with the /PWDMINIMUM qualifier. Generated passwords have an absolute length of 12 characters (see Section 7.3.2.3). Whenever there is a conflict between the value of /PWDMINIMUM and a generated password, the operating system uses the lesser of the two values.

Passwords you specify with AUTHORIZE are defined as expired by default. This forces the user to change the initial password when first logging in. See Section 7.3.2 for more information. Be sure to include information on the first login in your user training so that users know what to expect. If you do not want the password you define with AUTHORIZE to be pre-expired, add the qualifier /NOPWDEXPIRED when entering the password. This is necessary for accounts when users are not permitted to set their own password.

Pre-expired passwords are conspicuous in the UAF record listing. The entry for the date of the last password change carries the following notation:
(pre-expired)

7.3.1.2. System Passwords

Section 3.2.1 introduces system passwords, which control access to particular terminals. System passwords are used to control access to terminals that might be targets for unauthorized use, as follows:
  • All terminals using dialup lines or public data networks for access

  • Terminals on lines that are publicly accessible and not tightly secured, such as those in computer laboratories at universities

  • Terminals not frequently inspected

  • Terminals intended for use only as spare devices

  • Terminals you want to reserve for security operations

Execute the following steps to to implement system passwords:
  1. Establish a record in the SYSUAF database for a system password by invoking the Authorize utility and entering the following command:
    UAF> MODIFY/SYSTEM_PASSWORD=password

    Note

    You need to establish a record in the SYSUAF database only the first time a system password is set up on the system. However, if no record is present, the SET PASSWORD/SYSTEM command returns the following error:
    %SET-F-UAFERR, error accessing authorization file -RMS-E-RNF, record not found
  2. Decide which terminals require system passwords. Then, for each terminal, enter the DCL command SET TERMINAL/SYSPWD/PERMANENT. When you are satisfied that you have selected the right terminals, incorporate these commands into SYS$MANAGER:SYSTARTUP_VMS.COM so that the terminal setup work is done automatically at system startup. You can remove the restriction on a terminal at any time by invoking the DCL command SET TERMINAL/NOSYSPWD/PERMANENT for that terminal.

  3. Choose a system password, and implement it with the DCL command SET PASSWORD/SYSTEM, which requires the SECURITY privilege. This command prompts you for the password and then prompts you again for verification, just as for user passwords. To request automatic password generation, include the /GENERATE qualifier.

To enable the use of the system password for the remote class of logins (those accomplished through the DCL command SET HOST), set the appropriate bit in the default terminal characteristics parameter by using AUTOGEN. This is bit 19 (hexadecimal value 80000) in the parameter TTY_DEFCHAR2. Note that if you set this bit, you must invoke the DCL command SET TERMINAL/NOSYSPWD/PERMANENT to disable system passwords for each terminal where you do not want the feature. (As before, consider placing the SET TERMINAL commands you have tested in SYS$MANAGER:SYSTARTUP_VMS.COM.) Then follow the previously defined steps to set the system password.

When choosing a system password, follow the recommendations presented in Section 3.8. Choose a string of characters and digits, with a minimum length of 6, that is not a valid word. Although the system password is not subject to expiration, change the password frequently. Always change the system password as soon as a person who knows the password leaves the group. Share the system password only with those who need to know.

The system password is stored in a separate UAF record and cannot be displayed. The DCL command SET PASSWORD/SYSTEM (the normal means of setting and changing the system password) requires that you enter the old system password before changing it. Use the AUTHORIZE command MODIFY/SYSTEM_PASSWORD to change the system password without specifying the old password, as shown in the following command:
UAF> MODIFY/SYSTEM_PASSWORD=ABRACADABRA

The primary function of the system password is to form a first line of defense for publicly accessible ports and to prevent potential intruders from learning the identity of the system. However, requiring system passwords can appear confusing when authorized users are unaware that they are required on certain terminals. To avoid false reports of defective terminals or systems, inform your users which terminals allocated for their use require system passwords.

Where system passwords are not applied to either control access through dialup lines or on publicly accessed lines, few people may know the system password. Operations are hampered if the personnel who know the password are unavailable, incapacitated, or forgetful. Solve this problem by invoking AUTHORIZE and entering the MODIFY/SYSTEM_PASSWORD command. SYSPRV privilege is required.

7.3.1.3. Secondary Passwords

Sites with high-level security concerns can require a second password on user accounts. Typically, the user does not know the secondary password, and a supervisor or other key person must be present to supply it. For certain applications, the supervisor may also decide to remain present while the account is in use. The effectiveness of a secondary password depends on the trustworthiness of the supervisor who supplies it because the supervisor can remove the secondary password by changing it to a null string.

Although the use of dual passwords is cumbersome, they do offer the following advantages:
  • When used on a widespread basis, dual passwords help verify the identity of each user at login time because the supervisor or other key person can check each user.

  • When used in limited cases, dual passwords single out accounts that can be logged in to only when two persons are present.

  • Dual passwords also prevent the use of access control strings when users access accounts through DECnet software.

Sites with medium security requirements may use dual passwords as a tool when there are unexplained intrusions after the password has been changed and use of the password generator has been enforced. Select problem accounts, and make them a temporary target of this restriction. If the problem goes away when you institute personal verification through the secondary password, you know you have a personnel problem. Most likely, the authorized user is revealing the password for the account to one or more other users who are abusing the account.

Implement dual passwords with the AUTHORIZE qualifier /PASSWORD. For example, to impose dual passwords on a new account, invoke AUTHORIZE and use the following form of the ADD command:
ADD newusername /PASSWORD=(primarypwd, secondarypwd)
To impose a secondary password on an existing account, use the following form of the MODIFY command:
MODIFY username /PASSWORD=("", secondarypwd)
This command does not affect the primary password that already exists for the account but adds the requirement that a secondary password be provided at each subsequent login. The secondary password acquires the same password lifetime and minimum length values in effect for the primary password. If the /FLAGS=GENPWD qualifier has been specified for this account, the secondary password can be changed only under the control of the automatic password generator. You cannot use wildcards in the user name parameter to apply a secondary password to multiple users with a single command.

Note

While you can specify secondary passwords for accounts requiring remote access through the DCL command SET HOST, you cannot specify them for accounts requiring network file access using access control strings. If an account with a secondary password is to be used for network access (for example, remote file access), you must set up proxy access for all remote nodes from which the account may be accessed.

7.3.1.4. Console Passwords

The console terminal controls operation of the CPU and, consequently, operation of the system. Sites with high security requirements should consider using the password security feature when it is available. (Certain VAXstation 3100s and later models offer it.)

Once the console password is enabled, operators must enter it before using any privileged command in console mode. Privileged commands include the following two types:
  • Commands that examine or modify memory and registers, such as SET, EXAMINE, DEPOSIT, FIND, and SHOW.

  • Commands that transfer control of the CPU from the console monitor to another program, such as BOOT and START. (Invoking the default boot, which requires a BOOT command with no parameters, is not a privileged command and is allowed without the password.)

To enable the console password feature, take the following steps:
  1. Enter the privileged command:
    >>> SET PSWD 
  2. In response, the console prompts for a password:
    1 >>>
    Enter the new password, and press the Return key. Note that the console does not display the password as you enter it.

    The password must be a hexadecimal string of characters (0 through 9 and A through F) with a length of exactly 16 characters.

  3. If the password character string is of the right length, the console prompts for you to reenter the new password for verification:
    2 >>>
    Reenter the new password, and press Return. Again, note that the password is not displayed.
  4. Enable the password security feature with the following command:
    >>> SET PSE 1

To place the workstation in privileged mode and make all console commands accessible, use the LOGIN command. The SHOW PSE command displays the current status of the password feature. (If a 1 is displayed, the feature is enabled; a 0 indicates it is disabled.) To disable the feature, use the SET PSE command with a 0 argument.

Because the password is stored in nonvolatile memory, you must call the Customer Support Center if you forget it.

7.3.1.5. Authentication Cards

Rather than distribute passwords and account information, some sites choose to provide system users with hand-held devices called authentication cards or smart tokens.

Authentication devices have the user's password programmed onto them. Depending on the complexity of the hardware design, these devices can support additional login information (for example, an account name and billing reference number). A variety of authentication devices are available from third-party vendors. Such devices are supported by a software module that communicates with the login program (LOGINOUT.EXE). See the VSI OpenVMS Utility Routines Manual for a description of the LOGINOUT routines supporting authentication cards.

7.3.2. Enforcing Minimum Password Standards

You can use AUTHORIZE to impose minimum password standards for individual users. Specifically, qualifiers and login flags provided by AUTHORIZE control how soon passwords will expire, whether the user is forced to change passwords at expiration, and the minimum password length.

7.3.2.1. Expiring Passwords

With the AUTHORIZE qualifier /PWDLIFETIME, you can establish the maximum length of time that can elapse before the user is forced to change the password or lose access to the account. By default, the value of /PWDLIFETIME is 90 days. You can change the frequency requirements for user password changes by specifying a different delta time value for the qualifier. For example, to require a user to change the password every 30 days, you would specify the qualifier as /PWDLIFETIME=30-0.

The /PWDLIFETIME qualifier applies to both primary and secondary user passwords but not to the system password. Each primary and secondary password for a user is subject to the same maximum lifetime. However, the passwords can change at separate times. As soon as the user completes a password change, that individual password's clock is reset; the new password value can exist unchanged for the length of time dictated by /PWDLIFETIME.

The qualifier /NOPWDLIFETIME specifies that primary and secondary passwords do not expire.

Note

Specifying /NOPWDLIFETIME removes the default behavior that initial passwords be reset. However, if you want to have initial passwords reset but you do not want password expiration, you can specify /PWDLIFETIME="9999-".

AUTHORIZE also provides two login flags related to primary and secondary password expiration. These flags, PWD_EXPIRED and PWD2_EXPIRED, are specified with the /FLAGS qualifier. The first flag, PWD_EXPIRED, is set after the primary password expires and the user has had one last chance to change the password and has failed to do so. The second flag, PWD2_EXPIRED, is set after the secondary password expires and the user has had one last chance to change the secondary password and has failed to do so. If either PWD_EXPIRED or PWD2_EXPIRED is set, the account is disabled for logins because the user failed to employ the last chance to change the password during the last login.

As soon as the user successfully changes the password, the system resets the flags, as appropriate. The flag PWD_EXPIRED becomes NOPWD_EXPIRED as soon as the primary password is changed. Similarly, the flag PWD2_EXPIRED becomes NOPWD2_EXPIRED as soon as the secondary password is changed. As security administrator, you may choose to invoke AUTHORIZE and reset the flags, giving the user another chance to reset the password.

The use of a password lifetime forces the user to change passwords regularly. The lifetime can be different for different users. Users with access to critical files generally should have the shortest password lifetimes.

System passwords have an unlimited lifetime. It is your responsibility as security administrator to change the system password regularly.

Note

SYS$PASSWORD_HISTORY_LIFETIME should be made larger than the UAF parameter PWDLIFETIME. If you set the SYS$PASSWORD_HISTORY_LIFETIME value to less than PWDLIFETIME, passwords will expire out of the history file before they expire in SYSUAF. This defeats the purpose of the password history file. For more information about PWDLIFETIME parameter, see Section 7.3.2.2.

The LGI$PASSWORD_NOCHANGE_DAYS and LGI$EXPIRATION_WARNING_DAYS logicals are systemwide, executive-mode logical names.

You can define the LGI$PASSWORD_NOCHANGE_DAYS logical to set the minimum number of days before the user can change the password.

The LGI$EXPIRATION_WARNING_DAYS logical can be defined to set the number of days prior to the expiration of password when the user shall start receiving the password expiration warning messages.

7.3.2.2. Enforcing Change of Expired Password

By default, users are forced to change expired passwords when logging in. Users whose passwords have expired are prompted for new passwords at login. This password feature is valid only when a password expiration date is specified with the /PWDLIFETIME qualifier.

To disable forced password changes, specify the following qualifier to the ADD or the MODIFY command:
/FLAGS=DISFORCE_PWD_CHANGE
Once you disable the forced password feature, you can reenable it by clearing the login flag, as shown in the following:
/FLAGS=NODISFORCE_PWD_CHANGE
Users who log in and are prompted to change expired passwords can cancel the login by pressing Ctrl/Y.

Note

If secondary passwords are in effect and both primary and secondary passwords have expired, the user is forced to change both passwords. If the user changes the primary password and presses Ctrl/Y before changing the secondary password, the user is logged out, and no password change is recorded.

7.3.2.3. Requiring a Minimum Password Length

With the AUTHORIZE qualifier /PWDMINIMUM, you can direct that all password choices, both primary and secondary, must contain a minimum number of characters. (Users can still specify passwords up to the maximum length of 32 characters.)

A user's minimum password length is either the default of 6 characters or another value established by the /PWDMINIMUM qualifier (provided the number is 10 or less).

On Alpha systems, the password generator creates passwords of the exact length specified but limited to 10 characters.

On VAX systems, the password generator creates passwords that range in length between n and n+2, where the minimum length n is a value ranging from 1 to 10. So the length of a generated password (/GENERATE_PASSWORD or SET PASSWORD/GENERATE) can conflict with the value provided with the /PWDMINIMUM qualifier.

When there is a conflict between n and the value set by the /PWDMINIMUM qualifier, the operating system uses the lesser value, but never more than 10. For example, if you specify a length of 25 with the /PWDMINIMUM qualifier, the operating system generates passwords of 10 to 12 characters. The system does not notify you of the difference in values.

The length of a generated password produced by the AUTHORIZE qualifier /GENERATE_PASSWORD comes from the Pwdminimum field of the source UAF record: the DEFAULT record or the UAF record copied. The Pwdminimum field is updated with the value set by /PWDMINIMUM, so passwords created with SET PASSWORD/GENERATE use the new value.

The system password is not subject to a minimum length. Guidelines that apply to user passwords are equally applicable to system passwords. Choose system passwords that are 1 to 32 characters long.

7.3.2.4. Generated Passwords

The /FLAGS=GENPWD qualifier in AUTHORIZE lets you force use of the automatic password generator when a user changes a password. At some sites, all accounts are created with this qualifier. At other sites, the security administrator may be more selective.

If users will have access to sensitive data that must not be compromised by an intrusion, require them to use the password generator.

If your policy is to request voluntary use of the password generator and users are not cooperating, you can force users to use the password generator by adding the /FLAGS=GENPWD qualifier to pertinent user accounts. You can also add the AUTHORIZE qualifier /FLAGS=LOCKPWD to user accounts to prevent users from changing passwords. Only you will be authorized to change passwords.

7.3.2.5. Site Password Algorithms

The operating system protects passwords from disclosure through encryption. OpenVMS algorithms transform passwords from plaintext strings into ciphertext, which is then stored in the system user authorization file (SYSUAF.DAT). Whenever a password check is done, the check is based on the encrypted password, not the plaintext password. The system password is always encrypted with an algorithm known to the operating system.

The /ALGORITHM qualifier in AUTHORIZE allows you to define which algorithm the operating system should use to encrypt a user's password. Your choices are the current OpenVMS algorithm or a site-specific algorithm. You can specify the encryption algorithm independently for each account's primary and secondary passwords. The syntax is as follows:
/ALGORITHM=keyword=type [=value]
To assign the OpenVMS password encryption algorithm for a user, you would enter a command like the following:
UAF> MODIFY HOBBIT/ALGORITHM=PRIMARY=VMS
If a site-specific algorithm is selected, you must give a value to identify the algorithm, for example:
UAF> MODIFY HOBBIT/ALGORITHM=CURRENT=CUSTOMER=128

The VSI OpenVMS Programming Concepts Manual provides directions for using a customer algorithm. You must create a site-specific system service in which you write code that recognizes the algorithm number you choose and encrypts the password appropriately. This number has to correspond with the number used in the AUTHORIZE command MODIFY/ALGORITHM.

Whenever a user is assigned a site-specific algorithm, AUTHORIZE reports this information in the display provided by the SHOW command.

7.3.3. Screening New Passwords

The system generally compares new passwords against a system dictionary stored in SYS$LIBRARY to ensure that a password is not a native language word. It also maintains a history list of a user's passwords and compares each new password against this list to guarantee that an old password is not reused. You can screen passwords further by developing and installing an image that filters passwords for words that are particularly sensitive to a site.

7.3.3.1. System Dictionary

The DCL command SET PASSWORD takes a user's proposed password, converts it to lowercase (if necessary), and compares it to entries in a system dictionary to ensure that a password is not a native language word. If a proposed password is found in the dictionary, it is rejected as a valid user password, and the user has to provide another.

You may want to modify the system password dictionary to include words of significance to your site. The following procedure lets you add words to the system dictionary. The procedure also lets you retain a file of the passwords that you consider unacceptable.
  1. Create a file containing passwords you would like to add to the dictionary. Each password should be on a separate line and in lowercase, as follows:
    $ CREATE LOCAL_PASSWORD_DICTIONARY.DATA
    somefamous
    localheroes
    Ctrl/Z
  2. Enable SYSPRV and merge your local additions:
    $ SET PROCESS/PRIVILEGE=SYSPRV
    $ CONVERT/MERGE/PAD LOCAL_PASSWORD_DICTIONARY.DATA -
    _$ SYS$LIBRARY:VMS$PASSWORD_DICTIONARY.DATA

You can disable the dictionary search by using AUTHORIZE with the DISPWDDIC option to the /FLAGS qualifier.

7.3.3.2. History Lists

The operating system maintains a list of a user's passwords from the last 365 days and compares each proposed password against this list to ensure that passwords are not reused.

Once a user successfully creates a new password, the system enters the old password on the history list and updates the file. The password history list can hold a large number of words, but it is limited to 60 by default. If this number is exceeded, the user has to use generated passwords. A password remains on the password history list for 365 days (or the default set by SYS$PASSWORD_HISTORY_LIFETIME). Whenever a user account is deleted, the system removes all password records belonging to that account.

Using the DCL command DEFINE, you can change the defaults for the capacity and lifetime of the password history list to any of the values indicated in Table 7.4.
Table 7.4. Defaults for Password History List

System Logical Name

Default

Min

Max

Units

SYS$PASSWORD_HISTORY_LIFETIME

365

1

28000

Days

SYS$PASSWORD_HISTORY_LIMIT

60

1

2000

Absolute count

For example, to increase the capacity of the history list from 60 passwords to 100, add the following line to the command procedure SYLOGICALS.COM, which is located in SYS$MANAGER:
$ DEFINE/SYSTEM/EXEC SYS$PASSWORD_HISTORY_LIMIT 100

There is a correspondence between the lifetime of a password history list and the number of passwords allowed on the list. For example, if you increase the password history lifetime to 4 years and your passwords expire every 2 weeks, you would need to increase the password history limit to at least 104 (4 years times 26 passwords a year). The password history lifetime and limit can be changed dynamically, but they should be consistent across all nodes on the cluster.

Sites using secondary passwords may need to double the password limit to account for the secondary password storage.

The password history list is located in SYS$SYSTEM. You can move the list off the system disk by using the logical name VMS$PASSWORD_HISTORY. Define this logical name as /SYSTEM/EXEC, and place it in SYS$MANAGER:SYLOGICALS.COM.

You disable the history search with the DISPWDHIS option to the /FLAGS qualifier in AUTHORIZE.

7.3.3.3. Site-Specific Filters

Besides screening passwords against a system dictionary and a history list, you can develop a site-specific password filter to ensure that passwords are properly constructed and are not words readily associated with your site. A filter can check for password length, the use of special characters or combinations of characters, and the use of product names or personnel names.

To create a list of site-specific words, you write the source code, create a shareable image, install the image, and, finally, enable the policy by setting a system parameter. See the VSI OpenVMS Programming Concepts Manual for instructions.

Installing and enabling a site-specific password filter requires both SYSPRV and CMKRNL privileges. Multiple security alarms are generated when the password filter image is installed if INSTALL and SYSPRV file-access auditing are enabled and the required change to the system parameter is noted on the operator console.

The shareable image contains two global routines that are called by the Set Password utility (SET PASSWORD) whenever a user changes a password.

Caution

The two global routines let you obtain both the proposed plaintext password and its equivalent quadword hash value. All security administrators should be aware of this feature because its subversion by a malicious privileged user will compromise the system's security.

VSI recommends that you place security Alarm ACEs on the password filter image and its parent directory. See the VSI OpenVMS Programming Concepts Manual for instructions.

7.3.4. Password Protection Checklist

In addition to all the recommendations included in Section 3.8, observe the following guidelines to protect passwords:
  • Make certain the passwords on the standard accounts like SYSTEM are secure and changed regularly. You can disable accounts (for example, FIELD and SYSTEST) with the AUTHORIZE qualifier /FLAGS=DISUSER when they are not in use.

  • Do not permit an outside or in-house service organization to dictate the password for an account they use to service your system. Such service groups tend to use the same password on all systems, and their accounts are usually privileged.

  • On seldom-used accounts, set the AUTHORIZE qualifier /FLAGS=DISUSER, and enable the account only when it is needed. Change the password immediately after each use, and notify the service group of the new password when they need it next.

  • Delete accounts no longer in use.

  • Do not leave listings of user names where they can be read or stolen because they can be used as a basis for system attack. (If you do need listing files, use ACLs to limit access only to selected individuals.)

  • Maintain adequate protection of authorization files. Note that the system user authorization file (SYSUAF.DAT), the network proxy authorization file (NETPROXY.DAT), and the rights list (RIGHTSLIST.DAT) are owned by the system account ([SYSTEM]). Do not create any other user accounts in this group. Normally the default UIC-based file protection for these authorization files is adequate. The system account also owns the file NET$PROXY.DAT.

  • Make certain that all users have unique UICs.

The following actions reduce the potential of password detection or limit the extent of the damage if passwords are discovered or bypassed:
  • Avoid giving multiple users access to the same account.

  • Protect telephone numbers for dialup lines connected to your system, and consider setting a system password (SET TERMINAL/SYSPASSWORD) on dialup lines.

  • If your system has accounts available to outside users, such as guest accounts or accounts for direct customer inquiry, make these accounts captive (limited-access) accounts contained by captive command procedures. (See Section 7.2.4 for information about setting up captive accounts.)

  • Make captive all accounts that do not require a password.

  • Extend privileges to users carefully.

  • Protect your own files using all the techniques recommended in Section 5.4.8.

  • Ensure that the files containing components of the operating system are adequately protected (see Section 8.9.2).

  • Use the AUTHORIZE qualifiers /NOINTERACTIVE and /NOBATCH when setting up proxy login accounts to permit only file access from other nodes. Interactive and batch logins are disabled for the account.

7.4. Enabling External Authentication

External authentication allows users to log in at the OpenVMS login prompt using their external user IDs and passwords. When successfully authenticated, the external user ID is mapped to the appropriate OpenVMS user name and the correct user profile is obtained.

To enable external authentication, the system administrator must perform the following tasks:

  • For VSI OpenVMS Version 8.4-1H1 and later:
    1. Configure the ACME SERVER and ACME authentication agents

    2. Switch the login process from the default UAF LOGIN to the ACME LOGIN

    3. Mark user accounts in the SYSUAF file

  • For OpenVMS Versions 8.3—8.4:

    1. Configure the ACME SERVER and ACME authentication agents

    2. Install the ACMELOGIN kit

    3. Mark user accounts in the SYSUAF file

  • For OpenVMS Version 8.2-1 and earlier:

    1. Define external authentication logical names for non-SYS$ACM-enabled external authentication

    2. Mark user accounts in the SYSUAF file

7.4.1. Configuring the ACME SERVER and ACME authentication agents

The ACME SERVER is a multithreaded server that supports one or more authentication policies. Each authentication policy is applied by installing and configuring an ACME authentication agent.

For detailed information about the Authentication and Credentials Management Extensions (ACME) subsystem, see Section 7.4.17.

For a list of generic commands that you can use to configure the ACME SERVER, see Section 7.4.17.3.

OpenVMS supports the following ACME authentication agents:

  • VMS ACME authentication agent:

    The VMS ACME authentication agent provides the standard OpenVMS authentication policy. The VMS ACME authentication agent is always required for a complete operational environment, though there are other external authentication agents.

    No separate installation or configuration steps are required for this authentication agent. However, if you start the ACME_SERVER process manually using the SET SERVER ACME commands, you must configure the VMS ACME software in order to grant persona-based credentials. Use the following commands to start the ACME_SERVER process and configure ACME authentication agents:

    $ SET SERVER ACME/START/LOG
    $ SET SERVER ACME/CONFIG=(NAME=VMS,CRED=VMS)
    $ SET SERVER ACME/ENABLE
  • LDAP external authentication agent:

    The LDAP external authentication agent validates a user name and password against directory servers such as Active Directory and Enterprise Directory.

    For more information on how to install the LDAP external authentication agent, see the SYS$HELP:ACMELDAP_STD_CONFIG_INSTALL.PDF or SYS$HELP:ACMELDAP_STD_CONFIG_INSTALL.TXT. PDF version includes images along with the installation procedure.

  • MSV1_0 external authentication agent:

    The MSV1_0 external authentication agent is the Advanced Server for the VMS ACME agent that provides external authentication using the Microsoft NT LAN distributed authentication protocol. This agent is included in the installation of the Advanced Server for OpenVMS layered product.

    For more information about implementing external authentication using the Advanced Server, see the HP Advanced Server for OpenVMS Server Administrator's Guide.

    For information on installing and configuring the Advanced Server, see the HP Advanced Server for OpenVMS Server Installation and Configuration Guide.

  • Kerberos external authentication agent:

    The Kerberos SIP kit is installed during the installation of OpenVMS.

    For more information on configuring Kerberos, see the section called "Configuring and Starting the Kerberos ACME Agent" in the HP Open Source Security for OpenVMS, Volume 3: Kerberos guide.

7.4.2. Switching Between UAF LOGIN and ACME LOGIN

Starting with VSI OpenVMS Version 8.4-1H1, the OpenVMS system disk supplies two variants of the LOGINOUT.EXE and SETP0.EXE images:
  • The default non-SYS$ACM-enabled variant (UAF LOGIN)

  • The SYS$ACM-enabled variant (ACME LOGIN) that supports external authentication

To switch between UAF LOGIN and ACME LOGIN, use the SYS$MANAGER:SYS$LOGIN_SWITCH.COM command file. The SYS$LOGIN_SWITCH command procedure determines which login process is currently in use on your system and tells which one is about to switch to (see Example 7.5).
Example 7.5. Switching to ACME LOGIN
$ @SYS$MANAGER:SYS$LOGIN_SWITCH.COM
You are currently using UAF LOGIN.
This procedure will switch to using ACME LOGIN
Do you want to continue? (YES or NO): yes
The replacement procedure is complete.
If you run SYS$LOGIN_SWITCH on the system that uses a common system disk in an OpenVMS cluster, you must run the following commands on all cluster members using the common system disk:
$ INSTALL REPLACE LOGINOUT
$ INSTALL REPLACE SETP0
To check the image identification, use the following commands:
$ ANALYZE/IMAGE/INTER SYS$COMMON:[SYSEXE]LOGINOUT.EXE
$ ANALYZE/IMAGE/INTER SYS$COMMON:[SYSEXE]SETP0.EXE

You must get LOGIN98 as a part of the "Image file identification:" field, for the SYS$ACM-enabled images.

When you complete switching between the login processes on your system, it is recommended to log in with any user account to test the LOGINOUT replacement.

7.4.3. Installing the ACMELOGIN Kit

OpenVMS Versions 8.3—8.4 provide the SYS$ACM-enabled LOGINOUT.EXE and SETP0.EXE images for external authentication with the ACMELOGIN PCSI kit. This ACMELOGIN PCSI kit has to be extracted from SYS$UPDATE:ACME_DEV_KITS.BCK and installed.

See the SYS$HELP:ACME_DEV_README.TXT for the detailed information on installing the SYS$ACM-enabled LOGINOUT.EXE and SETP0.EXE images.

Also, see Section 7.4.17 for more details on how external authentication works when SYS$ACM system service is used with DCL commands to operate on the ACME subsystem.

7.4.4. Define Logical Names for Non-SYS$ACM-enabled External Authentication

OpenVMS Version 8.2-1 and earlier provides the non-SYS$ACME-enabled external authentication. The non-SYS$ACME external authentication is enabled at the system level by defining the SYS$SINGLE_SIGNON systemwide executive-mode logical name.

For more information, see Section 7.4.6.

By default, external authentication is disabled at both the system and user levels. However, when you invoke PATHWORKS or Advanced Server for OpenVMS, external authentication is automatically enabled, if the system administrator has defined logical names in SYSTARTUP_VMS.COM and marked user accounts in the SYSUAF, as described in the following paragraphs. No additional configuration is necessary on cluster members running the Advanced Server to enable the Advanced Server to participate in the external authentication process.

Note

The SYS$SINGLE_SIGNON logical name is automatically defined to 1 (enabled) by PWRK$ACME_STARTUP.COM (the PATHWORKS and Advanced Server for OpenVMS startup procedure) if it has not yet been defined in SYSTARTUP_VMS.COM. If you want to disable external authentication or set the SYS$SINGLE_SIGNON logical name to another value, define SYS$SINGLE_SIGNON in SYSTARTUP_VMS.COM before PATHWORKS or Advanced Server for OpenVMS is started.

You need to define the logical name PWRK$ACME_SERVER if you installed only the standalone Advanced Server external authentication images, and you have not installed the full Advanced Server. (Advanced Server installation gives the option of installing external authentication images only instead of the complete Advanced Server file and print server software. See the PATHWORKS (Advanced Server) or Advanced Server for OpenVMS Installation and Configuration Guide for more information. (See Table 7.5 for more information on the SYS$SINGLE_SIGNON logical name bits.)

For example:
$ DEFINE/SYSTEM/EXECUTIVE SYS$SINGLE_SIGNON 0

7.4.5. Marking User Accounts in the SYSUAF File

Each externally authenticated user must have an entry in the SYSUAF file from which account information such as account restrictions and quotas are fetched during login.

The user name in the SYSUAF record can be the same or different from the user name entered at the user name prompt. It depends on user name mapping support provided by the authentication agent, which validates the user.

For example, Kerberos external authentication supports one to one mapping where the user name entered and the user name in the SYSUAF file must be same.

At the user level, external authentication is enabled by a flag, EXTAUTH, in the SYSUAF record for the user. When set, the EXTAUTH flag denotes that the user is to be externally authenticated. For example, in the Authorize utility, you can enter commands similar to the following:

$ SET DEFAULT SYS$SYSTEM
$ RUN AUTHORIZE
UAF> ADD username /FLAGS=([NO]EXTAUTH)
UAF> MODIFY username /FLAGS=([NO]EXTAUTH)

See the VSI OpenVMS System Management Utilities Reference Manual, Volume 1: A-L for more information on the Authorize utility EXTAUTH flag. See the VSI OpenVMS Utility Routines Manual for more information on the UAI$V_EXTAUTH bit in the SYS$GETUAI and SYS$SETUAI system services UAI$_FLAGS item code.

7.4.6. Differences between SYS$ACM and non-SYS$ACM external authentication

The LOGINOUT.EXE and SETP0.EXE (SET PASSWORD) images, provided with the ACMELOGIN kit (upon extracting SYS$UPDATE:ACME_DEV_KITS.BCK), utilize the SYS$ACM system service for user authentication and password changes. With these images installed, login and password change requests are sent to the SYS$ACM service and handled by the ACME_SERVER process’s authentication agents. The effect must be transparent to users, layered products and applications.

If your site uses external authentication provided by Advanced Server and you are using the SYS$ACM-enabled LOGINOUT.EXE and SETP0.EXE images, you must be aware of how SYS$ACM-enabled external authentication operates compared with releases prior to Version 8.2–1.

  • Non-SYS$ACM-enabled external authentication (OpenVMS Version 8.2–1 and earlier):

    • SYS$SINGLE_SIGNON logical name is used to enable/disable external authentication and debugging using OPCOM messages.

    • Internal hooks in LOGINOUT.EXE and SETP0.EXE enforce authentication and password changes using Advanced Server.

    • Microsoft NT LAN Manager is the only authentication option.

    • /LOCAL requires OPER privilege on the target OpenVMS account.

    • Users are not prompted for a new LAN Manager password when it expires.

    • LAN Manager last login information is not displayed.

  • SYS$ACM-enabled external authentication (OpenVMS Version 8.3 and later):

    • External authentication is controlled by SET SERVER ACME commands.

    • SET SERVER ACME/TRACE writes diagnostic information to SYS$MANAGER:ACME$SERVER.LOG for debugging purposes.

    • LOGINOUT.EXE and SETP0.EXE utilize the SYS$ACM system service for authentication and password changes.

    • Other authentication options besides Microsoft NT LAN Manager are possible.

    • /LOCAL requires the VMSUATH flag on the target OpenVMS account.

    • Users are prompted for a new LAN Manager password when their current LAN Manager password has expired.

    • LAN Manager last login information is displayed during login.

7.4.7. Overriding External Authentication

Users can enter the /LOCAL_PASSWORD qualifier after their OpenVMS user name at the login prompt to inform OpenVMS to perform local authentication instead of external authentication. Users should specify their OpenVMS user name and password when using the /LOCAL_PASSWORD qualifier.

For SYS$ACM-enabled external authentication (OpenVMS Version 8.3 and later):

The SYSUAF flag /VMSAUTH denotes that the account can use standard (SYSUAF) authentication when the EXTAUTH flag requires external authentication. An application specifies the OpenVMS domain of interpretation when calling SYS$ACM to request standard OpenVMS authentication for a user account that normally uses external authentication.

For non-SYS$ACM-enabled external authentication (OpenVMS Version 8.2–1 and earlier):

As the use of the /LOCAL_PASSWORD qualifier is effectively overriding the security policy established by the system manager, it is only allowed under the following conditions:

  • When the account being logged into has SYSPRV as an authorized privilege.

  • When bit 1 is set in the SYS$SINGLE_SIGNON logical name, nonprivileged users (who are normally externally authenticated) can request local authentication.

See the VSI OpenVMS Utility Routines Manual for more information on the /LOCAL_PASSWORD qualifier to LOGINOUT.

7.4.8. Impact on Layered Products and Applications

Certain layered products and applications that use an authentication mechanism based on the traditional SYSUAF-based user name and password (for example, software that calls $HASH_PASSWORD or $GETUAI/$SETUAI to alter, fetch, or verify OpenVMS passwords) encounter problems in either of the following cases:

  • When external authentication is used in an environment where a given user's external user ID and OpenVMS user name are different

  • Where the user's SYSUAF password is different from the external user password

In such cases, the symptom is a user authentication failure from the layered product or application.

For externally authenticated users, the normal system authorization database (SYSUAF.DAT) is used to construct the OpenVMS process profile (UIC, privileges, quotas, and so on) and to apply specific login restrictions. However, there are two key differences between externally authenticated users and normal OpenVMS users. The following is true for externally authenticated users:

  • The password stored in the SYSUAF is not the password used to verify the user.

  • The user name stored in the SYSUAF and used to identify the OpenVMS process is not necessarily the same as the external user ID used to authenticate the user during login.

OpenVMS attempts to keep a user's SYSUAF and external user password synchronized to minimize these problems. An up-to-date copy of the user's external password is kept in the SYSUAF, but this is not the case if, for example, the external password contains characters that are invalid in OpenVMS, or if SYSUAF password synchronization is disabled by the system manager. (Password synchronization is enabled by default.)

If you enable external authentication, VSI recommends you do the following to minimize incompatibility with layered products or applications that use traditional SYSUAF-based authentication:

  • Do not disable password synchronization.

  • Limit external user passwords to those characters from the OpenVMS valid password character set (A—Z, 0—9, underscore (_), and dollar sign ($)).

  • Assign users the same user name in both the external authentication service and OpenVMS.

  • Do not assign the same user name or user ID to more than one user.

The $GETUAI and $SETUAI system services do not support external passwords. These services operate only in passwords stored in the SYSUAF, and updates are not sent to the external authentication service. Sites using software that makes calls to these services to check passwords or updates must not enable external authentication. VSI expects to provide a new programming interface to support external passwords in a future release.

7.4.9. Setting a New Password

If you are an externally authenticated user, the DCL command SET PASSWORD sends the password change request to the external authenticator and changes your password on your OpenVMS system.

A system manager can set an externally authenticated user's password by using a utility provided by the external authenticator. In the case of NT-compatible authentication, PATHWORKS and Advanced Server for OpenVMS provide the ADMINISTRATOR SET PASSWORD command. Using this method, the new password is propagated to the external authenticator immediately.

7.4.10. Case Sensitivity in Passwords and User Names

You can enter a case-sensitive user name at the OpenVMS username prompt if you enclose it in quotes. If you do not enclose the user name in quotes, LOGINOUT converts the user name to uppercase characters.

However, all user name entries in the SYSUAF file are stored in uppercase characters. A case insensitive search is performed in the SYSUAF file to locate the user record.

Valid characters for external user IDs and passwords belong to the standard IBM extended (8-bit) ASCII character set. LOGINOUT and SET PASSWORD pass these strings case preserved, although the external authentication service uppercases both strings according to this character set.

External passwords can contain characters that are not valid in OpenVMS passwords. If an external password contains a character that is invalid in an OpenVMS password, password synchronization is not performed and a message is issued.

OpenVMS passwords are limited to the 7-bit ASCII characters A—Z, 0—9, _, and $.

7.4.11. User Name Mapping and Password Verification

To be externally authenticated, a user provides his or her external user ID and password at the OpenVMS login prompt. When performing user name mapping, OpenVMS first tries to locate a match in the SYSUAF and uses that name if it finds a match; otherwise, it queries the external authentication database for a matching user ID. When successfully authenticated, the LAN Manager user ID is mapped to the appropriate OpenVMS user name to obtain the correct user profile, and the login sequence is completed.

External authentication is supported for interactive logins (including DECwindows) and network logins where a proxy is used or a user ID/password is supplied.

If you have external authentication enabled on your system, target user names specified in DECnet proxies or Auto-Login (ALF) databases must exist in the SYSUAF. Externally-authenticated users who want to use DECnet proxies must have the same user name in the SYSUAF file and LAN Manager database.

When using DECnet proxies, it is important to maintain unique user names across OpenVMS and LAN Manager domains. If the same user name appears in the SYSUAF file and LAN Manager database identifying two different users, the use of this user name as a proxy is ambiguous. LOGINOUT treats the name as an OpenVMS user name for login purposes, even though the same name in LAN Manager may map to a different OpenVMS user name. This occurs because name-mapping rules specify that OpenVMS attempt to find a match in the SYSUAF before LAN Manager.

Externally authenticated users are considered to have a single password and are not subject to normal OpenVMS password policy (password expiration, password history, minimum and maximum password length restrictions), but are instead subject to any defined external authenticator policy. All other OpenVMS account restrictions remain in effect, such as disabled accounts, modal time restrictions, quotas, and so on.

Externally authenticated users are identified by having the EXTAUTH flag set in their SYSUAF record. OpenVMS users whose accounts do not have the EXTAUTH flag set are not affected by external authentication.

7.4.12. Password Synchronization

Although passwords are verified using the external authenticator database, OpenVMS attempts to keep the external and SYSUAF password fields synchronized.

Password synchronization is enabled by default.

Synchronization takes place at the completion of a successful externally authenticated login. If the external password is different than the password stored in the SYSUAF file, LOGINOUT updates the SYSUAF password field with the external password. (Synchronization may not be possible due to the different sets of valid characters allowed by OpenVMS and the external authenticator.)

For SYS$ACM-enabled external authentication, if required, the password synchronization can be selectively turned off. See the section called “System Parameter SECURITY_POLICY Bit Mask Values” for more information on the SECURITY_POLICY system parameter, which controls the enabling and disabling of password synchronization.

For non-SYS$ACM-enabled external authentication, if required, password synchronization can be selectively turned off. (See Table 7.5 for more information on the SYS$SINGLE_SIGNON logical name bits, which control the enabling and disabling of password synchronization.)

7.4.13. Specifying the SYS$SINGLE_SIGNON Logical Name Bits

For non-SYS$ACM-enabled external authentication (OpenVMS Version 8.2–1 and earlier), the SYS$SINGLE_SIGNON systemwide executive-mode logical name controls overall external authentication operation. The logical name is translated as a hexadecimal string and treated as a bit vector, with each bit controlling a separate component.

Table 7.5 contains the definitions of the SYS$SINGLE_SIGNON logical name bits, which are numbered from right to left (with the least significant bit first).
Table 7.5. SYS$SINGLE_SIGNON Logical Name Bits

Bit #

Status

Description

0

ON

Enable external authentication. Users who are tagged in the SYSUAF file as externally authenticated use the external authenticator to log in.

OFF

Disable external authentication. If local authentication is enabled (that is, bit 1 is ON), then the system attempts local authentication with the user's normal SYSUAF user name and password. If local authentication is disabled, login is not allowed for externally authenticated users.

1

ON

Enable local authentication. If bit 0 is off, the system automatically logs the user in using local authentication. (The system effectively ignores the EXTAUTH flag in the user's SYSUAF record.) If bit 0 is on but the external authentication server is not running, the user can request local authentication using the /LOCAL_PASSWORD qualifier.

OFF

Disable local authentication. A user can force local authentication using the /LOCAL_PASSWORD qualifier. You must have SYSPRV privilege to use this qualifier when bit 1 is OFF.

2

ON

Reserved to OpenVMS.

OFF

Reserved to OpenVMS.

3

ON

Enable forced uppercase terminal input during login; this is equivalent to the RMS ROP$V_CVT option for the login device. Setting this bit restores previous OpenVMS behavior but does not allow case-sensitive input of user name and password.

OFF

Disable forced uppercase terminal input during login.

4

ON

Disable local password synchronization. The system does not perform password synchronization from the external authenticator to the SYSUAF.

OFF

Enable local password synchronization. During a successful login, the system attempts to synchronize the SYSUAF password with the external password (if they are different) by calculating the OpenVMS hash value of the external password used for logins and storing the hash value in the SYSUAF file.

31

ON

Enable OPCOM debug messages, which are displayed when users log in or use the SET PASSWORD command. These messages can help diagnose potential problems with the configuration of external authentication.

OFF

Disable OPCOM debug messages.

If SYS$SINGLE_SIGNON is undefined or equates to an invalid hexadecimal string, all bits are considered OFF.

The following example definition enables external authentication (bit 0). All other components take their default values.
$ DEFINE/SYSTEM/EXECUTIVE SYS$SINGLE_SIGNON 1
The following example definition enables external authentication (bit 0), forces uppercase terminal input at the username prompt (bit 3), and disables password synchronization (bit 4).
$ DEFINE/SYSTEM/EXECUTIVE SYS$SINGLE_SIGNON 19 !19 HEX

7.4.14. VSI DECnet-Plus Requirement

Users with the EXTAUTH bit set in their SYSUAF account record cannot use explicit access control strings with systems running DECnet-Plus unless their externally authenticated password is all uppercase characters.

For example, if you enter the following command:

$DIRECTORY nodename "username password"::

where nodename is a system running DECnet-Plus and username is an EXTAUTH account, DECnet-Plus converts the string supplied in the password to uppercase characters before it is passed to the external authentication agent (a PATHWORKS or NT domain controller).

There are two workarounds:

  • If you are using DECnet-Plus and you want to use explicit access control strings, define an uppercase NT password.

  • Set up a proxy account on your DECnet-Plus nodes so that you do not have to use explicit access control strings to perform functions.

7.4.15. DECnet-Plus and NET_CALLOUTS Parameter

To run DECnet-Plus for OpenVMS with external authentication enabled, set the system parameter NET_CALLOUTS to 255. This causes user verification and proxy lookups to be done in LOGINOUT rather than DECnet.

7.4.16. Failed Connection Attempts on POP Server

The Post Office Protocol (POP) server does not use external authentication to authenticate connection attempts on the OpenVMS system. This causes connection attempts to fail if either of the following conditions exist:

  • The external user ID is different from the OpenVMS user name.

  • The OpenVMS password is not synchronized with the external user password.

7.4.17. Authentication and Credentials Management Extensions (ACME) Subsystem

This section describes how the SYS$ACM system service provides external authentication capability to applications that have to authenticate a user on an OpenVMS system.

The Authentication and Credentials Management Extensions (ACME) subsystem provides authentication and persona-based credential services. Applications can use these services to interact with the user to perform one or more of the following functions:

  • User authentication

  • Password change

  • Persona creation and modification

ACME supports standard OpenVMS authentication and external authentication policies; therefore, applications utilize the same mechanisms as used by the system's LOGINOUT and SET PASSWORD components.

7.4.17.1. ACME Subsystem Overview

The ACME subsystem consists of the following components:

  • SYS$ACM system service

    SYS$ACM is a context-driven system service. The service is designed so that applications adapt themselves transparently to various authentication dialogs without requiring changes to the application. Applications call SYS$ACM to perform functions such as authenticate-principal and change-password. Upon successful authentication, the service can return a complete security profile of the user in the form of a persona. For further information about SYS$ACM, see the VSI OpenVMS System Services Reference Manual and the VSI OpenVMS Programming Concepts Manual.

  • ACME_SERVER process

    The ACME_SERVER process is a multithreaded server that supports one or more authentication policies. Each authentication policy is installed by configuring an ACME agent shareable image that "plugs in" to the ACME_SERVER process by way of a standard interface. The server manages the authentication sequence by calling each ACME agent in turn, according to a defined sequence of phases. ACME agents are also responsible for adhering to certain rules regarding how agents can interact during an authentication sequence.

    The ACME_SERVER process must be restarted if the installed password policy is changed.

  • ACME agents or authentication agents

    ACME agents each define a single authentication policy that augments or replaces portions of the standard OpenVMS authentication policy. OpenVMS currently supports the following ACME authentication agents:

    • VMS authentication agent

    • LDAP external authentication agent

    • MSV1_0 external authentication agent

    • Kerberos external authentication agent

    For more information on how to install and configure these authentication agents, see Section 7.4.1.

  • DCL commands SET and SHOW SERVER ACME

    You can configure and manage the ACME subsystem by using the SET and SHOW SERVER ACME commands.

7.4.17.2. ACME Agent Operational Environment

The ACME subsystem supports multiple ACME agents that can interact with each other to complete an authentication request. These interactions must occur in a controlled manner.

When a user authentication dialog is in process, one ACME agent is the controlling agent and the other agents operate in the background as secondary agents.

The controlling agent directs the user name and password prompts and is ultimately responsible for validating the user. The secondary agents can display messages, request additional passwords, issue credentials, or reject the authentication request, depending on how each agent is configured to interact with other agents.

7.4.17.3. ACME Subsystem Controls

Operational control of the ACME subsystem includes the following:

Start, Stop, Restart, and Configure ACME_SERVER Process and ACME Agents

The ACME_SERVER process starts automatically upon system boot, with the VMS ACME agent configured.

Start or Restart ACME_SERVER with all required ACME agents configured by default

OpenVMS Version 8.3 and later uses a site specific startup procedure, SYS$MANAGER:ACME$START.COM. You can edit the SYS$MANAGER:ACME$START.COM to enable the configuration of the various ACME agents that are required and also the order in which the agents are started.

The SYS$MANAGER:ACME$START.COM is run as a result of one of the following conditions:

  • SET SERVER ACME/START=AUTO command is issued.

  • SET SERVER ACME/RESTART command is issued.

  • Unexpected condition causes an automatic server restart.

If you enable agents other than VMS ACME agent, edit the SYSTARTUP_VMS.COM procedure also to include the following command after all the dependent ACME agents:

$ SET SERVER ACME/RESTART

This ensures that all the required ACME agents are started automatically upon system boot.

The executive-mode logical name ACME$START is used to locate this file.

ACME Agent Ordering

The ACME_SERVER can be configured to enable the agent in a specific order. When the user enters the username, at the user name prompt, the ACME agents are called in the order in which it is enabled. The first agent to successfully map the user's principal name to a valid user name within its domain, validates the user.

The ordering of the ACME agents is important if the same principal name exists in two or more ACME agent domains. The first agent to map it successfully controls the authentication request.

By default, however, it is recommended that the VMS ACME agent is configured first. For example, if the Kerberos authentication agent is configured on OpenVMS and the order of startup for OpenVMS and Kerberos ACME agent is such that the Kerberos agent is started first, only those accounts belonging to Kerberos can login.

If the startup order is changed, you can change it back to the default order by performing the following procedure:

Edit the SYS$MANAGER:ACME$START.COM (This file is available on OpenVMS Version 8.3 and later) to search for the section (near the end of the command procedure) where you can specify the desired agent ordering. Change the last line (beginning with AGENT_LIST) so that it appears in the procedure.

$! A specific agent ordering can be specified in AGENT_LIST.
$!
$! If the list is empty, the agents will be enabled in the order that
$! they were configured. Some agent startup procedures may alter
$! the agent order. You can override that ordering here. Consult the
$! agent documentation you are using to ensure that the ordering you
$! specify is supported by that agent.
$!
$! For example
$!
$! AGENT_LIST = "VMS,MSV1_0"
$!
$! will enable the VMS and MSV1_0 agents (and only those agents) in
$! that order.
$!
$ AGENT_LIST = "VMS,ACME_KRB_DOI"

Note

User applications can be developed to directly call SYS$ACM system service and direct it to specific ACME agent overriding the order.

Steps to manually configure the various ACME agents

To start or stop the server manually, use these commands:

$ SET SERVER ACME/START
$ SET SERVER ACME/EXIT [/ABORT]

On providing a manual SET SERVER ACME/START command, all the ACME agents including the VMS ACME agent have to be configured manually.

To configure the VMS ACME agent, use the following command:

$ SET SERVER ACME/CONFIGURE=(NAME=VMS,CRED=VMS) 

To configure the LDAP ACME agent, run the YS$STARTUP:LDAPACME$STARTUP-STD.COM command procedure or use the following command:

$ SET SERVER ACME/CONF=(NAME=LDAP-STD,FACILITY=LDAPACME,CRED=LDAP)

Note

To use the LDAP agent, ACMELDAP_STD kit must be installed and configured. For more information, see Section 7.4.1.

To configure the MSV1_0 ACME agent, run the SYS$STARTUP:NTA$STARTUP_NT_ACME.COM command procedure or use the following command:

$ SET SERVER ACME/CONFIGURE=(NAME=MSV1_0,CRED=NT, FAC=PWRK)

Note

To use the MSV1_0 ACME agent, the Advanced Server product must be installed and running. For more information, see Section 7.4.1.

To configure the Kerberos ACME agent, run SYS$STARTUP:KRB$STARTUP_KERBEROS_ACME.COM command procedure or use the following command:

$ SET SERVER ACME/CONFIGURE=(NAME=ACME_KRB_DOI, -
_$ FACILITY=KRB,CREDENTIAL=KRB)

Note

To use the Kerberos agent, the Kerberos ACME agent must be installed and configured. For more information, see Section 7.4.1.

When the ACME agents are configured, enable them using the following command:

$ SET SERVER ACME/ENABLE[=NAME=agent]

Error information is written to the ACME subsystem log file, SYS$MANAGER:ACME$SERVER.LOG.

Other ACME Agent Commands

To view the state of the ACME subsystem, use the following command:

$ SHOW SERVER ACME [/FULL] [/AGENT=agent] 

Problems can be diagnosed by turning on tracing:

$ SET SERVER ACME/TRACE=n

For more information on the commands, see the VSI OpenVMS DCL Dictionary.

To configure the number of worker threads, use the following command:
SET SERVER ACME/CONFIG=THREAD_MAX

This command is ignored on Integrity servers because only one worker thread is active.

Note

Do not increase the number of threads on Integrity servers. Increasing the number of threads on Integrity servers might lead to ACME_SERVER process crash and login failures.

SYSUAF Flags

These flags can be manipulated by SYS$SETUAI, SYS$GETUAI, and the AUTHORIZE utility on VAX, Alpha, and Integrity systems. Only the ACME subsystem on Alpha and Integrity servers recognizes these flags.

FlagDescription
EXTAUTHExternal authentication is enabled for the user, when this flag is set in the SYSUAF record.
VMSAUTH

When this flag is set, the user account can use standard (SYSUAF) authentication, even if the EXTAUTH flag is set for the user, which requires external authentication. An application specifies the OpenVMS domain of interpretation (DOI) when calling SYS$ACM to request standard OpenVMS authentication for a user account that normally uses external authentication.

Users can enter the /LOCAL_PASSWORD qualifier after their OpenVMS user name at the login prompt to inform OpenVMS to perform local authentication instead of external authentication, when this flag is set for the user in the SYSUAF file.

DISPWDSYNCHDo not synchronize the external password for this account. See the GUARD PASSWORD control bit in the SECURITY_POLICY system parameter for systemwide password synchronization control.
System Parameter SECURITY_POLICY Bit Mask Values

The following security policy bits control systemwide ACME subsystem operation on Alpha:

  • Guard Passwords

    Set this bit to disable password synchronization among ACME agents on a systemwide basis. This is functionally equivalent to the SYS$SINGLE_SIGNON logical name bit mask value 4 for LOGINOUT.

    The hexadecimal value is 200.

  • Allow NoAuthorization

    Set this bit to allow privileged applications to successfully authenticate a user whose principal name maps to a SYSUAF record that is either expired or whose modal restrictions would otherwise prevent the account from being used. A SYSUAF record that is disabled or password-expired (in the case of traditional VMS authentication) cannot be bypassed in this manner. An application with SECURITY privilege specifies the SYS$ACM ACME$M_NOAUTHORIZE function modifier to override authorization checks.

    The hexadecimal value is 400.

  • Ignore ExtAuth and VMSAuth SYSUAF flags

    Set this bit to allow any record in the SYSUAF file to be mapped using external authentication.

    The hexadecimal value is 800.

7.4.17.4. Authentication Policies

An authentication policy is defined by a particular combination of user identification, authentication, and authorization attributes. Policy attributes include:

  • Identification syntax

    Includes simple user name and combination of domain/realm/principal name.

  • Authentication token mechanism

  • Token reuse filters

    Includes password dictionary, password history, password legal character set, password minimum and maximum lengths, forced change schedule, and expiration.

  • Intrusion detection

  • Case sensitivity

  • Access restrictions

    Includes time of day, day of week, and type of access.

  • User account controls

    Includes account lock (disable) and account expiration.

  • Credential information

    Includes user and group identifiers and privileges.

The following authentication policies are supported at present:

  • Standard OpenVMS policy

  • LDAP authentication policy

  • External authentication with Advanced Server for OpenVMS distributed authentication policy

  • Kerberos authentication policy

OpenVMS policy

The OpenVMS policy is a rich, case-insensitive, password-based authentication policy that includes single-password or dual-password accounts, password expiration, password lock, password expiration, minimum password lengths, system-generated passwords, intrusion detection and evasion, password dictionary and history filters, modal access restrictions, account expiration, and account lock.

A user's credential information consists of the user's group and member identifier code (UIC), privileges, and rights identifiers. This information is stored in the system authorization (SYSUAF.DAT) and rights identifier (RIGHTSLIST.DAT) databases.

The system authorization database also contains information about how and when the user can access the system. These modal restrictions limit access based on time of day, day of week, and type of access (for example, dialup, remote, or batch).

OpenVMS credentials are stored in a persona. A persona is a protected, kernel-based data structure.

LDAP authentication policy

The LDAP authentication policy is based on the Lightweight Directory Access Protocol. It supports validation against the user name and password located on the Directory Server, mapping the user to the OpenVMS user name in the SYSUAF file. For more information on LDAP, see the SYS$HELP:ACMELDAP_STD_CONFIG_INSTALL.PDF or SYS$HELP:ACMELDAP_STD_CONFIG_INSTALL.TXT.

The credentials, such as the user and group identifiers and privileges, use the standard OpenVMS policy.

Advanced Server for OpenVMS policy

The Advanced Server for OpenVMS MSV1_0 authentication policy is a distributed authentication policy based on Microsoft LAN Manager domain protocols. It supports password and challenge-response (NTLM) mechanisms. The policy supports case-sensitive passwords, password expiration, minimum time before password change, and account lock.

A user's credential information consists of the user's system identifiers (primary and secondary SIDs) and privileges.

Advanced Server for OpenVMS credentials are stored in an NT persona extension that is attached to a standard persona containing the OpenVMS credentials of the OpenVMS user name that has been mapped to the Microsoft user name by the Advanced Server database.

Kerberos authentication policy

The Kerberos authentication policy is based on the Kerberos protocol. It supports validation against the user name and password located on the Kerberos key distribution center database. The Kerberos principal name must be the same as the OpenVMS user name in SYSUAF.

The credentials, such as the user and group identifiers and privileges, use the standard OpenVMS policy.

7.5. Controlling the Login Process

This section describes many operating system features designed to secure systems from unauthorized users.

7.5.1. Informational Display During Login

This section describes how you can control the display of various pieces of information that appear by default at login time, such as announcement, welcome, last login, and new mail messages. So that you can understand the effect of login restrictions, it also describes how the operating system processes the login fields of the system user authorization file (SYSUAF.DAT). In addition, this section describes the use of the secure server and how to set up intrusion detection.

7.5.1.1. Announcement Message

To provide an announcement message on your system, define the system logical name SYS$ANNOUNCE in the site-specific startup command procedure SYS$MANAGER:SYSTARTUP_VMS.COM. The VSI OpenVMS System Manager's Manual describes how to do this. The announcement message appears at login.

The definition you provide here affects all users on the system. Because this message may provide a clue to the identity of the operating system, you may decide not to display it.

7.5.1.2. Welcome Message

Similar to the announcement message, the welcome message is controlled through a system logical name, SYS$WELCOME. If you do not define SYS$WELCOME, a standard welcome message is provided for all users. This welcome message reveals the operating system and version number, as well as the node if SYS$NODE is defined.

To define another message for SYS$WELCOME, you can create a text file containing the message. To display the contents of this file, use the following line in SYSTARTUP_VMS.COM:

$ DEFINE/SYSTEM SYS$WELCOME "@SYS$MANAGER:WELCOME.TXT"

To disable the welcome message, place the following DCL command in SYS$MANAGER:SYSTARTUP_VMS.COM. This command prints a blank line in place of the standard welcome message.

$ DEFINE/SYSTEM SYS$WELCOME " "

If you prefer to selectively disable the message for individual users, you can use the AUTHORIZE qualifier /FLAGS=DISWELCOME on individual UAF records.

7.5.1.3. Last Login Messages

By default, the system displays three messages that provide information about the last logins and the number of failed login attempts (see Section 3.4.3). You can selectively disable the appearance of these three messages. Enter the AUTHORIZE qualifier /FLAGS=DISREPORT for specific users.

7.5.1.4. New Mail Announcements

By default, the system tells users the number of new mail messages when they log in. You can prevent users from receiving this notice by specifying the AUTHORIZE qualifier /FLAGS=DISNEWMAIL.

The new mail announcement is primarily a user convenience, not a security issue. If a user with a restricted account cannot invoke the Mail utility (MAIL), then you might want to disable the new mail message at the same time you prohibit mail access. The following AUTHORIZE qualifier accomplishes both tasks:

/FLAGS=(DISMAIL,DISNEWMAIL)

7.5.2. Limiting Disconnected Processes

Virtual terminals let users maintain more than one disconnected process at a time. Virtual terminals are also required by the secure server feature (see Section 7.5.4). You may want to restrict the use of virtual terminals. For example, if you are concerned about the amount of nonpaged pool, you may not want to enable this feature on a systemwide basis.

Virtual terminals can be disabled at the terminal, user, or system level:

  • To prevent particular terminals from being used as virtual terminals, use the DCL command SET TERMINAL/PERMANENT/NODISCONNECT.

  • To prevent specific users from attaching to disconnected processes, set the AUTHORIZE qualifier /FLAGS=DISRECONNECT for those users. (An applications account used by multiple users is a good candidate for the DISRECONNECT flag to prevent the users from connecting to each other's processes.)

  • To disable virtual terminals on a systemwide basis, remove the DISCONNECT attribute from the system parameter TTY_DEFCHAR2.

You can also set the amount of time allowed for reconnection to less than the default of 15 minutes with the system parameter TTY_TIMEOUT. A process that remains disconnected for longer than the timeout value is automatically logged out by the system. Limiting the connection time tends to minimize the number of users who receive messages, but it also affects the usefulness of the connection feature.

For more information on setting up and reconnecting to virtual terminals, see the VSI OpenVMS System Manager's Manual.

7.5.3. Providing Automatic Login

You can assign accounts to particular terminals to enable an automatic login feature (see Section 7.2.6). This feature permits users to log in without specifying a user name. The operating system associates the user name with the terminal (or terminal server port) and maintains these assignments in the file SYS$SYSTEM:SYSALF.DAT, referred to as the automatic login file or the ALF file. Maintain this file with the following System Management utility (SYSMAN) commands:

TaskCommandExample
Adding terminal/user name associationALF ADDALF ADD TTA5 RENOLDS
Adding terminal server/user name associationALF ADD/PORT"M34C3/LC-1-2" RENOLDS
Displaying records in ALF fileALF SHOWALF SHOW TTA5 ALF SHOW /USERNAME=PONTRE
Removing terminal/user name associationALF REMOVEALF REMOVE TTA3 ALF REMOVE /USERNAME=DOUGLAS

The ALF file consists of one record for each terminal on which automatic logins are enabled. Each record consists of two fields: the device name or terminal server port name of the terminal, followed by the user name of an account. The device names must be unique within the file. However, the same user name can occur in any number of records; that is, one account can be automatically logged in to an unlimited number of terminals.

The ALF file is an indexed file that does not need to be purged, but it should be backed up after a modification.

7.5.4. Using the Secure Server

Section 3.8 describes password grabbers as a class of programs designed to steal passwords from unsuspecting users who log in to terminals left on. The operating system provides a secure terminal server that stops any currently executing process before the start of a login at that terminal.

Invoke the secure server separately for each terminal with the following DCL command:

SET TERMINAL/PERMANENT/SECURE/DISCONNECT term-id

The user must then press the Break key followed by the Return key to start a login. The login proceeds as usual.

If you apply the secure server to all terminals, you can make the login procedure consistent throughout the site by putting the SET TERMINAL commands in the site-specific startup command procedure. However, certain applications that may use the terminal as a communications line need to use the Break key for their own purposes, which would be incompatible with the secure terminal server.

The secure terminal server feature is also incompatible with autobaud handling. However, because autobaud handling is necessary only on modem terminals (switched and dialup terminals), the modem handling on such terminals performs the equivalent of secure server functions. For secure operation, set up the terminal characteristics as follows:

  • For local terminals (direct-wired), use the following SET TERMINAL qualifiers:

    /NOMODEM/SECURE/DISCONNECT/NOAUTOBAUD/PERMANENT

  • For switched terminals (data-switch and dialup), use the following SET TERMINAL qualifiers:

    /MODEM/AUTOBAUD/NOSECURE/DISCONNECT/PERMANENT

Specify the /DIALUP qualifier if the terminal port is accessible through a telephone line or the equivalent, regardless of the path (direct modem, data switch, terminal server, or public data network).

Always specify the /DISCONNECT qualifier to guard against password grabbers. To prevent disconnected jobs from filling up your system, set the system parameter TTY_TIMEOUT to a low timeout value, which determines when disconnected processes are deleted.

If you decide to apply the secure server to individual terminals, include directly wired terminals located in public areas or remote, unsecured areas. Terminals never used for local or dialup logins are not subject to this security problem. Terminals closely supervised during logins may also not require this measure.

7.5.5. Detecting Intruders

Occasionally people fail to log in correctly because they enter an expired password or make a typing error. But not all failures are benign: some occur because an unauthorized person is trying to log in through an expired account or with an unknown user name or is attempting to guess passwords on a valid account.

The operating system is sensitive to login failures. After one failure, it begins to monitor the terminal, terminal server connection, or network connection where the login is taking place. At first, the operating system records unsuccessful logins in an intrusion database. As failures continue, the operating system not only records failures but takes restrictive measures. The person attempting login is monitored more closely and limited to a certain number of login retries within a limited period of time. Once a person exceeds either the retry or time limitation, he or she cannot log in for a while, even with a valid user name and password. At a later point, the restriction eases, and login is allowed once again.

7.5.6. Understanding the Intrusion Database

The DCL command SHOW INTRUSION displays the contents of the intrusion database; Example 7.6 shows a sample display. The database captures the following types of information on login failures:

FieldDescription
Intrusion class

The general source of failure:

  • Network: failure originating from a remote node, using a valid user name

  • Terminal: failure originating from one terminal

  • Term_User: failure originating from one terminal, using a valid user name

  • Username: failure attempting to create a detached process

Type

Severity of login failure:

  • Suspect

  • Intruder

The system parameters for threshold count (LGI_BRK_LIM) and monitoring period (LGI_BRK_TMO) define when a suspect becomes an intruder.

CountNumber of login failures associated with a particular source.
ExpirationDate and time when a suspect's record is deleted or when an intruder is allowed another chance to log in. When an intruder's record reaches its expiration time, it becomes a suspect, and the failure count is reset to LGI_BRK_LIM. The expiration time is reset to the old expiration plus LGI_BRK_TMO.
Source

Origin of the login failure:

  • Node and user name if Network class

  • Terminal if Terminal class

  • Terminal and user name if Term_User class

  • User name if Username class

Whenever the system detects an intruder, it sends an auditing message to the security operator terminal or the log file to alert you. Using the DCL command SHOW INTRUSION, you can display the source and type of intrusion. For example, Example 7.6 shows a problem with a user named MAPLE who is logging in over the network. The user has tried to log in 8 times. Because the user failed to log in within the monitoring period, the operating system suspended all logins from OMNI:.BOSTON.BIRCH::MAPLE. Example 7.6 gives a more detailed explanation of how the system decides to suspend logins.

Notice that many suspects appear in the display. Sometimes users forget their passwords or type them incorrectly. To remove an entry from the database, use the DCL command DELETE/INTRUSION_RECORD.

Example 7.6. Intrusion Database Display
$SHOW INTRUSION
Intrusion    Type      Count       Expiration             Source
   NETWORK   SUSPECT     1    2-Jan-2009 13:20:30.89    PCD025::

Intrusion    Type      Count       Expiration             Source
   NETWORK   SUSPECT     5    2-Jan-2009 13:36:39.42    DENIM::SYSTEM
   NETWORK   SUSPECT     2    2-Jan-2009 13:25:17.30    N1KDO::SYSTEM

Intrusion    Type      Count       Expiration             Source
   NETWORK   SUSPECT     2    2-Jan-2009 13:07:57.95    OMNI:.LOWELL.ASH::TESTER
   NETWORK   INTRUDER    8    2-Jan-2009 11:06:50.51    OMNI:.BOSTON.BIRCH::MAPLE

Intrusion    Type      Count       Expiration             Source
   NETWORK   SUSPECT     2    2-Jan-2009 13:20:10.09    JETTE::TIPH
   NETWORK   SUSPECT     1    2-Jan-2009 13:21:40.75    FTSR::TFREDERICK

7.5.7. How Intrusion Detection Works

Once a login failure occurs, a user becomes a suspect and is monitored for further failures for a period of time. The operating system tolerates only so many login failures by the suspect during this given period of time before it declares the source of login failure to be an intruder. In other words, suspects become intruders by exceeding their allowed chances for login during the monitoring period.

The chance count, set by the system parameter LGI_BRK_LIM, defines how many times a person can try logging in; the standard limit is five times. The chance parameter works in tandem with a time factor controlled by the system parameter LGI_BRK_TMO. At each login failure, the suspect's monitoring period is increased by the value of LGI_BRK_TMO. Thus, with each failure, the suspect is monitored for a longer period of time.

Table 7.6 illustrates a situation where evasive action results when user George fails five times to log in. At each failure, the monitoring period is extended by 5 minutes. On the fifth failure, the operating system labels George an intruder and refuses to log him in. (Notice that the example assumes the parameters LGI_BRK_LIM and LGI_BRK_TMO are both set to 5.)

Table 7.6. Intrusion Example
Time of Login FailureFailure CountExtension of Monitoring Period
6:000George fails to log in, and the system starts to monitor logins from George's terminal. It monitors for the next 5 minutes.
6:00:301Thirty seconds later, with 4.5 minutes left in the monitoring period, George fails again. The monitoring period is extended by 5 minutes. Thus, the system monitors George for login failures during the next 9.5 minutes.
6:012Thirty seconds later, 9 minutes remain in his monitoring period, and the system extends it by 5 minutes.
6:023One minute later, George has 13 minutes in his monitoring period, and the system extends it by 5 minutes.
6:02:304Thirty seconds later, George has 17.5 minutes in the monitoring perod, and the system extends it by 5 minutes. Thus, the system monitors George for login failures during the next 22.5 minutes.
6:04:305Two minutes later, George makes a sixth attempt. Even though the monitoring period allows the time, he runs out of chances. He becomes an intruder and can no longer access the system.

7.5.8. Setting the Exclusion Period

An intruder can be excluded temporarily or permanently, depending on system settings:

  • Temporary exclusion is controlled by the product of LGI_HID_TIM and a random number between 1 and 1.5. At the end of the temporary exclusion period, the subject is reclassified as a suspect. The monitoring period of the suspect is set by the value of LGI_BRK_TMO. For the new monitoring period, the failure count is set to LGI_BRK_LIM, allowing one more chance to log in before the subject is reclassified as an intruder.

  • Permanent exclusion results if LGI_BRK_DISUSER is set because this enables the DISUSER flag in a user authorization record when the operating system detects an intrusion.

Enabling the LGI_BRK_DISUSER parameter can have serious consequences because that user name is disabled until you manually intervene. If LGI_BRK_DISUSER is enabled, a malicious user can put all known accounts, including yours, out of service in a short time. To recover, you must log in on the system console where the SYSTEM account is always allowed to log in.

7.5.9. System Parameters Controlling Login Attempts

Table 7.7 describes the system parameters controlling login and intrusion detection.

Table 7.7. Parameters for Controlling Login Attempts
If You Want to Control...Set the ParameterDescription
Login time periodLGI_PWD_TMO

Allows time to:

  • Enter the correct system password (if used).

  • Enter personal account passwords.

  • Enter the old password, enter a new password, and verify it when using the SET PASSWORD command.

Number of times a person can try to log in over a phone line or network connectionLGI_RETRY_LIMAllows a person to retry the login sequence without losing the phone connection or network link as long as the retry time (LGI_RETRY_TMO) allows. Someone can reconnect and reattempt login as long as the break-in limit (LGI_BRK_LIM) has not been exceeded during the monitoring period.
Interval between login attempts over phone lines or network connectionLGI_RETRY_TMOSpecifies the number of seconds allowed between login attempts after a login failure. If there is no user response after a login failure for LGI_RETRY_TMO seconds, LOGINOUT disconnects the session.
Number of login chancesLGI_BRK_LIMSpecifies the number of login failures during the monitoring period that triggers evasive action. The failure count applies independently to login attempts by each user name, terminal, and node.
Length of failure monitoring periodLGI_BRK_TMOIndicates the time increment added to the suspect's expiration time each time a login failure occurs. Once the expiration period passes, prior failures are discarded, and the subject is given a clean slate.
Association of user name and terminal name in intrusion database source nameLGI_BRK_TERMControls whether failures from terminal class logins are counted by terminal, by user (the default), or by user across all terminals. LAT is tracked back to the originating port based on the contents of the TT_ACCPORNAM field.
Duration of login denialLGI_HID_TIMSpecifies the duration of login denial. The value of this parameter times a random number (between 1 and 1.5) determines the actual length of evasive action when the failure count has exceeded LGI_BRK_LIM.
Intruder's accountLGI_BRK_DISUSEREnables the DISUSER flag in user's authorization record, permanently locking out that account.

7.5.10. Security Server Process

The Security Server process, which is created as part of the normal operating system startup, performs the following tasks:

  • Creates and manages the system's intrusion database

  • Maintains the network proxy database file (NET$PROXY.DAT)

The system uses the intrusion database to keep track of failed login attempts. This information is scanned during process login to determine if the system should take restrictive measures to prevent access to the system by a suspected intruder. You can display the contents of this database by issuing the DCL command SHOW INTRUSION, as shown in Example 7.6. You can delete information from the database by issuing the DCL command DELETE/INTRUSION.

The network proxy database file (NET$PROXY.DAT) is used during network connection processing to determine if a specific remote user may access a local account without using a password. You can manage the information in this database with the Authorize utility.

Chapter 8. Controlling Access to System Data and Resources

This chapter describes how you design user groups and provide users with the identification (UICs, identifiers, privileges) they need to do their work. As part of the discussion, the chapter shows how to assign proper protection codes and ACLs to objects so that the user can work efficiently while, at the same time, system data and resources are properly protected. The chapter assumes you are familiar with the material in Chapter 4 and Chapter 5.

8.1. Designing User Groups

As you design user groups, remember that the groups you establish have an impact on data and resource protection and influence those who receive the GROUP, GRPNAM, and GRPPRV privileges. You may want to map out the functions you expect your users to perform. Look for groups of users involved with a common function, such as accounting, engineering, marketing, and personnel.

Think ahead to future plans in your organization. Incorporate these ideas into your strategy. You can fine-tune the group design at any time, but it is most important to gain a perspective on the logical groupings according to the functions your users perform.

Following are two guidelines for determining the placement of users in UIC groups:
  • Sharing: Users who typically share data and control of processes should be arranged in the same group.

  • Protection: Users who should not have access to each other's data or control each other's processes should be assigned to separate groups.

However, there are limitations to UIC group design. You may want to give only a few members of your UIC group access to files that you own, or you may want to grant access to your files to members of several UIC groups without having to grant world access. These limitations are described in Section 8.1.2.

8.1.1. Example of UIC Group Design

The fictitious Rainbow Paint Company is a distribution company with five departments: executive, accounting, marketing, shipping, and administration. Table 8.1 identifies the employees in the various departments who need computer resources. The table also lists the job responsibilities of the employees.
Table 8.1. Employee Grouping by Department and Function

Department

Employee

Function

Executive

Samuel Gibson

President

Olivia Westwood

Treasurer Head of Computer Operations

Accounting

Carlo Ruiz

Payroll

Rich Smith

Bookkeeping

Rod Jacobs

Clerk

Ruth Crandall

Clerk

Marketing

Jason Chang

Forecasting

Alana Mack

Sales Reporting

Shipping

Scott Giles

Inventory Control

Administration

Jane Simon

Correspondence Management Paycheck Printing

The fact that the company has been organized into departments suggests that individuals in the same department perform many of the same functions. For example, the advantage of grouping all the employees who perform bookkeeping tasks for the company in the accounting department is that employees can easily communicate with one another and gain access to the data they must share.

As the system manager of Rainbow Paint's computer resources, Olivia Westwood will set up UIC groups based on the existing organizational structure. For example, the employees in the accounting department (Ruiz, Smith, Jacobs, and Crandall) could be members of the UIC group ACCOUNTING. Setting up the UIC group in this way ensures that user Ruiz has easy access to data from user Smith, and so on.

Effective department organization ensures that only selected employees will have access to all data and employees in the company. For example, one of the functions of the accounting department concerns payroll. Because payroll information is confidential, employees in the shipping and marketing departments should not have access to that information.

As the system manager of Rainbow Paint's computer resources, Westwood sets up the UIC groups—ACCOUNTING, EXECUTIVE, MARKETING, SHIPPING, and ADMINISTRATION—corresponding to the various departments in the company. Members of a UIC group can be given common access to files, as shown in the following example:
$ SET SECURITY/PROTECTION=G:RWE GROUP_STATS.DAT

With this command, the owner of the file GROUP_STATS.DAT allows each member of the UIC group read, write, and execute access to the file.

8.1.2. Limitations to UIC Group Design

In some cases, UIC-based protection does not present the best solution to your object protection needs. If users in several UIC groups need access to common files and other resources on the system, the only UIC-based alternatives are to give world access to the object (all users can access the object) or to grant extended privileges to each user. Neither choice is desirable.

You may also need to allow users in a UIC group several types of access to files; you may want to deny access to the object to some users in the same group. Again, UIC-based protection does not offer a good solution to meet these needs.

Access control lists (ACLs), described in the following sections, offer another way to protect files and other objects on the system.

As the site security administrator, it is extremely important to familiarize yourself with the subtleties of the UIC categories, as described in Section 4.5. Putting users in certain UIC groups may grant them system privileges, and a user with system privilege has control access to any protected object on the system. The SYSPRV privilege is given by default to all UIC groups less than or equal to 10, but the actual range for the system UIC category is determined by the value of the MAXSYSGROUP system parameter. Putting users with the GRPPRV privilege in groups that own system files might also cause security problems.

8.2. Naming Individual Users in ACLs

Rather than attempting to restructure UIC groups to solve data and resource protection problems, you may be able to achieve your goals by using access control lists (ACLs). (Section 4.4 provides a detailed description of ACLs.) The UIC can serve as an identifier in an ACE, so you can easily construct ACLs that allow specific users across various UIC groups access to an object.

For example, consider the ACL that you might construct to allow specific users from the Rainbow Paint Company to access the file PAYROLL.DAT:
(IDENTIFIER=OWESTWOOD,ACCESS=READ+WRITE+EXECUTE+DELETE)
(IDENTIFIER=CRUIZ,ACCESS=READ+WRITE+EXECUTE+DELETE)
(IDENTIFIER=RSMITH,ACCESS=READ+WRITE+EXECUTE+DELETE)
(IDENTIFIER=JSIMON,ACCESS=READ) (IDENTIFIER=SGIBSON,ACCESS=READ)

8.3. Defining Sharing of Rights

Many users often share the same access needs, and an ACL consisting strictly of UIC identifiers can become too lengthy. To shorten the ACL, you can include environmental identifiers, which are system-defined, or create general identifiers (see Table 4.1).

When creating general identifiers, you design the names of the identifiers you want on your system and compose the set of holders for the identifiers. Then you add the identifiers to the rights database and assign the identifiers to the intended users.

For example, the Rainbow Paint Company decided to add the identifier PAYROLL to the rights database. The holders of that identifier were all users who needed read, write, execute, and delete access to PAYROLL.DAT: OWESTWOOD, CRUIZ, and RSMITH.

Once the identifier and its holders were defined, the security administrator used the following ACL to specify the same type of access to PAYROLL.DAT:
(IDENTIFIER=PAYROLL,ACCESS=READ+WRITE+EXECUTE+DELETE)
(IDENTIFIER=JSIMON,ACCESS=READ)
(IDENTIFIER=SGIBSON,ACCESS=READ)

8.4. Conditionalizing Identifiers for Different Users

A final step in designing ACLs and identifiers is to consider how and when different identifiers are going to be used. Users often need to hold an identifier for different reasons, such as updating databases or performing system operations. For this reason, you may want to qualify the use of an identifier.

There are several ways to qualify identifiers. One way is to use environmental identifiers, and another is to add special attributes to identifiers, as described in Section 8.6.7.

Environmental identifiers describe different types of users based on their initial entry into the system. These identifiers—local, dialup, remote, interactive, network, and batch—let you define a large potential group of users according to their use of the system. Typically, these types of identifiers are used in combination with other identifiers.

For example, the following ACE permits user Martin to have read, write, execute, and delete access to the object only when logged in from a local terminal:
(IDENTIFIER=MARTIN+LOCAL,ACCESS=READ+WRITE+EXECUTE+DELETE)
You can use the environmental identifiers in ACLs to deny access to an entire class of logins. For example, the following ACE denies access to all dialup users:
(IDENTIFIER=DIALUP,ACCESS=NONE)

In assigning these environmental identifiers to users in a DECwindows environment, remember that DECwindows processes can be virtually any type of process. For example, a user may choose to run DECwindows Mail in a batch job. Even though the process is communicating interactively with a user through a DECwindows workstation, it is still classified as a batch job.

8.5. Designing ACLs

There are several factors to consider when designing ACLs:
  • Using shorter ACLs with general identifiers has several advantages. The operating system processes shorter ACLs more rapidly. In addition, when employees change but the functions remain the same, you do not have to change every ACL across the system. Instead, you change the holders of the identifier. If employees leave the project, you can edit their records in RIGHTSLIST.DAT so they no longer hold the identifier, or if they leave the company, you can remove their user authorization file (UAF) records altogether. When new employees are hired for the same jobs, grant the new users the right to hold the identifier. The new users then have the same ACL-based access as the former users.

  • Your overall design should consider the types of files and other objects on your system and the protection needs of each. If you have successfully designated groups and identifiers, you should be able to easily design ACLs and define standard protection. Time spent clarifying the common access needs of your users simplifies the design of identifiers and ACLs. You will also simplify the job for your users who place ACLs on their files.

  • Do not use ACLs indiscriminately. They consume paged system dynamic memory when files are open. They also require additional processing time. ACLs are best applied where protection is really needed. If your ACLs become too long (for example, more than 200 entries or so), you might consider grouping users into discrete categories and creating general identifiers.

  • At the same time, do not create excessive numbers of identifiers. In particular, do not grant too many identifiers to one user. Having a user hold more than 10 or 20 identifiers may result in excessive time spent processing ACLs. If you find an individual holding too many identifiers, you may want to reconsider how your groups are structured. Or, if this is an exception case, consider putting the individual directly on the necessary ACLs.

For more information on defining identifiers, see Section 8.6 and the description of AUTHORIZE in the VSI OpenVMS System Management Utilities Reference Manual. For more information about creating and maintaining ACLs, see Chapter 4. For extensive work, using the access control list editor (ACL editor) is appropriate; the ACL editor is described in the VSI OpenVMS System Management Utilities Reference Manual.

8.6. Populating the Rights Database

Once you have designed the names of the identifiers you want on your system and composed the set of holders for the identifiers, use AUTHORIZE to add the identifiers to the rights database and assign the identifiers to the intended users. These associations are kept in the rights database (RIGHTSLIST.DAT), which you maintain as you add or remove users and identifiers.

Initially, the rights database is created at system installation and is located in the [SYSEXE] directory. At creation, it contains the names of the environmental identifiers. As you add users to the authorization file, one identifier is added for each authorized user. The identifier, called a UIC identifier, is associated with the user's UIC and user name.

There is also an identifier in the rights database equivalent to each UIC group name. When you add a new user as the first member of a new UIC group and you specify an account group name with the user, an identifier corresponding to the account group name is added to the rights database, as shown in the following example:
$ SET DEFAULT SYS$SYSTEM
$ RUN AUTHORIZE
UAF> ADD ROB/PASSWORD=SP0152/UIC=[014,006] -
_UAF> /DIRECTORY=WORK:[ROB]/ACCOUNT=MGMT
UAF-I-ADDMSG, user record successfully added
UAF-I-RDBADDMSGU, identifier ROB value: [000014,000006] added to RIGHTSLIST.DAT
UAF-I-RDBADDMSGU, identifier MGMT value: [000014,177777] added to RIGHTSLIST.DAT

Because the account name MGMT is specified when adding ROB's account and no UIC group of that name exists, the MGMT identifier is added to the rights database.

Each site adapts its own rights database according to actual use and needs.

Note that when you use AUTHORIZE to add, remove, or change user names in the system user authorization file (SYSUAF.DAT), AUTHORIZE makes corresponding changes for you in RIGHTSLIST.DAT so that the rights list corresponds to SYSUAF.DAT.

Because of the automatic creation and maintenance of the rights database, you seldom need to use the AUTHORIZE command CREATE/RIGHTS. However, if the rights database is damaged or deleted, you can create a new one with this command. (See the VSI OpenVMS System Management Utilities Reference Manual for more information.)

8.6.1. Displaying the Database

You should regularly display the rights database to check that it is correct and current. Two AUTHORIZE commands are used for this: SHOW/IDENTIFIER and SHOW/RIGHTS. To display all holders of an identifier, use the SHOW/IDENTIFIER command, as shown in the following example:
UAF> SHOW/IDENTIFIER/FULL NETWORK
Use the asterisk (*) wildcard to display all holders of all identifiers on the system, as follows:
UAF> SHOW/IDENTIFIER/FULL *
To display the identifiers held by a particular user, use the SHOW/RIGHTS command, as follows:
UAF> SHOW/RIGHTS/USER=ROBIN
Use the asterisk wildcard to display all identifiers held by all users, as follows:
UAF> SHOW/RIGHTS/USER=*
UAF> SHOW/RIGHTS/USER=[*,*]

The first command displays users alphabetically. The second command displays users according to UICs.

8.6.2. Adding Identifiers

You add identifiers to the rights list with the AUTHORIZE command ADD/IDENTIFIER, for example:
UAF> ADD/IDENTIFIER PAYROLL
identifier PAYROLL value %X80080011 added to RIGHTSLIST.DAT
To grant users an identifier with any of the attributes described in Section 8.6.7, you must name that attribute when adding the identifier. For example, to allow users to add or modify an identifier, specify the Dynamic attribute:
UAF> ADD/IDENTIFIER PROJECT_TEAM1 /ATTRIBUTES=DYNAMIC

8.6.3. Restoring the Rights Database

If you accidentally deleted the rights list and it cannot be recovered from a backup copy, recreate RIGHTSLIST.DAT by entering the CREATE/RIGHTS command, followed by the ADD/IDENTIFIER command, as follows:
UAF> CREATE/RIGHTS
{message}
UAF> ADD/IDENTIFIER/USER=*   or   ADD/IDENTIFIER/USER=[*,*]
{messages}

The ADD/IDENTIFIER command generates a UIC identifier in the rights list corresponding to each user name in SYSUAF.DAT. To complete the task, use the ADD/IDENTIFIER command to add all general identifiers that were lost. Then redefine the holders of the identifiers with GRANT/IDENTIFIER commands, as described in Section 8.6.4.

8.6.4. Assigning Identifiers to Users

After adding identifiers, you associate users as holders of the existing identifiers by using the AUTHORIZE command GRANT/IDENTIFIER, as shown in the following example:
UAF> GRANT/IDENTIFIER PAYROLL MARTIN
UAF-I-GRANTMSG, identifier PAYROLL granted to MARTIN
UAF> GRANT/IDENTIFIER PAYROLL IPPOLITO
UAF-I-GRANTMSG, identifier PAYROLL granted to IPPOLITO

To give user Martin the EXECUTIVE identifier in addition to the PAYROLL identifier would require another use of the GRANT/IDENTIFIER command. You can introduce only one holder association at a time with the GRANT/IDENTIFIER command.

In all cases shown above, AUTHORIZE associates the PAYROLL identifier with the UIC identifier corresponding to the user, specifically Martin and Ippolito. Both the identifiers must exist in the rights database.

8.6.5. Removing Holder Records

When a user leaves the company, remove the UAF record for that user. Notify the managers of all sites where that user has access to proxy accounts to remove proxy access information in the remote node's NETPROXY.DAT file. When you run AUTHORIZE to remove a user's UAF record, AUTHORIZE also removes the user's connections as a holder of identifiers in the rights database. However, if a departed user is the only remaining holder of a given identifier, remove that identifier to avoid future confusion.

8.6.6. Removing Identifiers

Before you remove an identifier from the rights database:
  1. Remove all occurrences of the identifier from ACLs on the system. For example, the following command removes the obsolete identifier 87SUMMER from the ACL of multiple files:
    $ SET SECURITY/ACL=(IDENTIFIER=87SUMMER)-
    _$ /DELETE/LOG  *.*;*
    You receive errors for files that do not contain the ACE, but the ACE is deleted from all files that do contain it.
  2. Remove the identifier 87SUMMER from the rights database with the AUTHORIZE command REMOVE/IDENTIFIER. For example, use the following AUTHORIZE command to remove the identifier 87TERM3:
    UAF> REMOVE/IDENTIFIER 87TERM3
    {message}

Identifiers in hexadecimal format in an ACE indicate that a general identifier has been deleted from the rights database. Similarly, if you see an identifier displayed as a numeric UIC, the original identifier was a UIC that has been removed. Delete ACEs with numeric UIC or hexadecimal identifiers.

It is wise not to reuse UICs after an employee leaves. The new employee may gain some or all of the access rights of the previous employee through ACL entries that still reference the old UIC in numeric format.

To rename an identifier, use the AUTHORIZE command RENAME/IDENTIFIER in the following format:
RENAME/IDENTIFIER old-identifier new-identifier

Renaming an identifier preserves the set of resources available through that identifier. ACLs containing the renamed identifier automatically display the new identifier name.

8.6.7. Customizing Identifiers

Whenever you add identifiers to the rights list or grant identifiers to users, you can stipulate that the identifier carry special characteristics called attributes. Although there are many possible attributes, most sites commonly use the following ones:

Dynamic attribute

Allows holders of the identifier to remove and to restore the identifier from the process rights list by using the DCL command SET RIGHTS_LIST.

Resource attribute

Allows holders of the identifier to charge disk space to the identifier. It is used for file objects.

Subsystem attribute

Allows holders of the identifier to create and maintain protected subsystems by assigning the Subsystem ACE to the application images in the subsystem.

No Access attribute

Makes any access rights of the identifier null and void. This attribute is intended as a modifier for a resource identifier or for purposes unrelated to access control.

Sites with high security requirements are likely to use two other attributes, which discourage users from scanning the rights database:

Holder Hidden attribute

Prevents someone from getting a list of users who hold an identifier unless that person owns the identifier.

Name Hidden attribute

Allows holders of an identifier to have it translated (either from binary to ASCII or vice versa), but prevents unauthorized users from translating the identifier.

Read access to RIGHTSLIST.DAT overrides the Holder Hidden and Name Hidden attributes. The rights list by default denies access to world users; it has a protection of S:RWED,O;RWED,G:R,W:.

The following sections describe each attribute and explain when you might want to add them to some of your site's identifiers.

8.6.7.1. Dynamic Attribute

Once you grant an identifier to a user, processes created by that user hold the identifier for the life of the process. However, if you grant the identifier with the Dynamic attribute, the user who holds the identifier can use the DCL command SET RIGHTS_LIST to add or remove the identifier or its attributes from the process rights list as needed.

To allow users to modify an identifier, specify the Dynamic attribute when adding the identifier to the rights database by using AUTHORIZE, as shown in the following example:
$ SET DEFAULT SYS$SYSTEM
$ RUN AUTHORIZE
UAF> ADD/IDENTIFIER MGMT101 /ATTRIBUTES=DYNAMIC
To allow specific holders of the identifier to modify the identifier, include the Dynamic attribute when granting the identifier, as follows:
UAF> GRANT/IDENTIFIER MGMT101/ATTRIBUTES=DYNAMIC SCHWARTZ
User Schwartz could then use the following command to remove the MGMT101 identifier from the process rights list:
$ SET RIGHTS_LIST/DISABLE MGMT101

Users who hold identifiers with the Dynamic and Resource attributes can also use the SET RIGHTS_LIST command to remove only the Resource attribute on the identifier.

Because users might be able to circumvent intended security policy by removing their identifiers, be careful when granting users an identifier with the Dynamic attribute. If an identifier is used in an ACL to deny access to users who hold that identifier with the Dynamic attribute, users may be able to gain access to the object through another ACL entry by removing the identifier from their process rights lists.

8.6.7.2. Holder Hidden Attribute

Sites with high security requirements can conceal the holders of certain identifiers, thereby preventing malicious users from determining which accounts are more interesting to target for break-ins.

You place the attribute on an identifier the user holds by using the AUTHORIZE command MODIFY/IDENTIFIER, for example:
UAF> MODIFY/IDENTIFIER /ATTRIBUTES=HOLDER_HIDDEN SECRET_PROJECT

Now the prober cannot discover who is on the secret project.

8.6.7.3. Name Hidden Attribute

Sites with high security requirements can hide the names of identifiers. For example, sites implementing mandatory access controls can hide the names of identifiers associated with their security categories. This prevents people from seeing the names of identifiers unless they personally hold them. When an identifier holds the Name Hidden attribute, the operating system refuses to translate the identifier from its binary value to ASCII or from ASCII to the binary value unless the requesting process holds the identifier.

To assign the attribute to an identifier, use the AUTHORIZE command MODIFY/IDENTIFIER:
UAF> MODIFY/IDENTIFIER SECRET_NEWS /ATTRIBUTES=NAME_HIDDEN

8.6.7.4. No Access Attribute

The No Access attribute allows a process to hold an identifier but not have the identifier considered in determining access rights to the object.

For example, a user with the Resource and No Access attributes can charge disk space to the identifier but not have access to objects owned by the identifier. Or a system manager can manage data and perform tasks connected with the data but cannot read from or write to any of the files.

You can allow file space to be owned by and charged to an identifier yet prevent the files from being accessed in any way. Use AUTHORIZE to specify the No Access attribute with the Resource attribute when adding the identifier to the rights database, as shown in the following example:
UAF> ADD/IDENTIFIER/ATTRIBUTES=(RESOURCE,NOACCESS)-
_UAF> MGMT101
To limit the rights of users holding an identifier with the Resource attribute, grant the identifier with the No Access attribute as well as the Resource attribute to all desired users:
UAF> GRANT/IDENTIFIER/ATTRIBUTES=(RESOURCE,NOACCESS)-
_UAF> MGMT101 SCHWARTZ

8.6.7.5. Resource Attribute

Consumption of disk space is generally charged to the creator of each file by subtracting the disk space from the file owner's disk quota. System managers and security administrators might prefer to track the use of disk space according to logical groups of users (such as departments or projects) rather than individual users. General identifiers are used to specify these groups. Thus, when general identifiers own directories, disk space used by files created in the directories may be charged to the identifier rather than the UIC of the file's creator.

To allow file space to be owned by and charged to an identifier, use AUTHORIZE to specify the Resource attribute when adding the identifier to the rights database, as shown in the following example:
UAF> ADD/IDENTIFIER MGMT101 /ATTRIBUTES=RESOURCE
To allow specific holders of the identifier to charge disk space to the identifier, perform the following steps:
  1. Grant the identifier with the Resource attribute to all desired users:
    UAF> GRANT/IDENTIFIER MGMT101/ATTRIBUTES=RESOURCE SCHWARTZ
  2. Modify the directory to allow read and write access to the resource identifier:
    $ SET SECURITY/ACL=(-
    _$ (IDENTIFIER=MGMT101,ACCESS=READ+WRITE) -
    _$ (IDENTIFIER=MGMT101,OPTIONS=DEFAULT,ACCESS=READ+WRITE))-
    _$ INVENTORY.DIR
  3. Change the ownership of the parent directory so that any files in it are owned by the identifier by default:
    $ SET SECURITY/OWNER=MGMT01 INVENTORY.DIR

Because resource identifier MGMT101 is going to own any file you create in directory INVENTORY.DIR, you use ACEs to determine the type of file access you receive. Include a Creator ACE (CREATOR,ACCESS=READ+WRITE+EXECUTE+DELETE) to set the access granted to the file's creator. Alternatively, you can let the system assign an ACE; its ACE grants control access to the file's creator plus the access specified in the owner field of the protection code. You can set up the protection code by including a Default Protection ACE in the ACL for INVENTORY.DIR, for example, (DEFAULT_PROTECTION, ACCESS=O:RW). (Refer to Section 8.8.1.2 for further information.)

Not everyone who holds the identifier will also hold the Resource attribute associated with that identifier. If you create a file in a directory owned by an identifier but you do not have the Resource attribute for that identifier, the file will be owned by your UIC, and the required disk space is subtracted from your disk quota.

8.6.7.6. Subsystem Attribute

You can authorize users to manage protected subsystems by granting them a subsystem identifier with the Subsystem attribute. This empowers users to enable images to access the objects managed by the subsystem. (See Chapter 14 for a discussion of protected subsystems.)

In the following example, user Schwartz is given the authority to create a subsystem with the identifier MAIL_SUBSYSTEM. Schwartz is also given control access to the application image to set access controls.
$ SET DEFAULT SYS$SYSTEM
$ RUN AUTHORIZE
UAF> ADD/IDENTIFIER MAIL_SUBSYSTEM /ATTRIBUTES=SUBSYSTEM
UAF> GRANT/IDENTIFIER MAIL_SUBSYSTEM -
_UAF> /ATTRIBUTES=SUBSYSTEM SCHWARTZ
UAF> Exit
$ SET SECURITY/ACL=(IDENTIFIER=MAIL_SUBSYSTEM,ACCESS=CONTROL)-
_$  MEMBER_LIST.EXE

8.6.8. Modifying a System or Process Rights List

As a privileged security administrator, you can use the SET RIGHTS_LIST command to modify the rights list of any process on the system or to modify identifiers in the system rights list. Adding an identifier to the system rights list effectively grants it to all users. You can also use the SET RIGHTS_LIST command to add attributes to existing identifiers.

A possible use of the system rights list is to enable site-specific environmental conditions. For example, a batch job scheduled to run at 8:00 a.m. could add the following identifier:
$ SET RIGHTS_LIST/SYSTEM/ENABLE DAY_SHIFT
Another batch job scheduled for 5:00 p.m. could remove the identifier DAY_SHIFT:
$ SET RIGHTS_LIST/SYSTEM/DISABLE DAY_SHIFT

The effect is to enable access to protected objects with the identifier DAY_SHIFT during the 8:00 a.m. to 5:00 p.m. period.

The command in the next example modifies a process rights list by adding the SALES identifier to the rights list of the process DEDNAM. Specifying the Resource attribute allows the holders of the SALES identifier to charge disk space to it.
$ SET RIGHTS_LIST/ENABLE/ATTRIBUTES=RESOURCE/PROCESS=DEDNAM SALES

8.7. Giving Users Privileges

Some system activities are limited to users who hold specific privileges. These restrictions protect the integrity of the operating system's performance and, thus, the integrity of service provided to users. Grant privileges to each user on the basis of two factors: (a) whether the user has a legitimate need for the privilege and (b) whether the user has the skill and experience to use the privilege without disrupting the system.

A user's privileges are recorded in the user's UAF record in two privilege vectors. One vector stores the authorized privileges, and the other vector stores the default privileges. The default privileges are the subset of authorized privileges that a user process receives at login.

When a user logs in to the system, the user's privilege vector is stored in the header of the user's process. In this way, the user's privileges are passed on to the process created for the user. Users can use the DCL command SET PROCESS/PRIVILEGES to enable and disable privileges for which they are authorized.

The operating system monitors and audits the use of privilege. You can enable auditing for specific privileges and examine the audit log file to see what privileges were used to execute DCL commands or system services. See Chapter 10 for further information.

8.7.1. Categories of Privilege

Privileges are divided into the following seven categories according to the damage that the user possessing them could cause the system:
  • None: No privileges

  • Normal: Minimum privileges to effectively use the system

  • Group: Potential to interfere with members of the same group

  • Devour: Potential to consume noncritical systemwide resources

  • System: Potential to interfere with normal system operation

  • Objects: Potential to compromise object security

  • All: Potential to control the system

Table 8.2 categorizes the privileges and includes a brief definition of the powers associated with each privilege.
Table 8.2. OpenVMS Privileges

Category

Privilege

Activity Permitted

None

None

Deny activities requiring privileges

Normal

NETMBX

TMPMBX

Create network connections

Create temporary mailbox

Group

GROUP

GRPPRV

Control processes in the same group

Gain access through the system protection field of the group's objects

Devour

ACNT

ALLSPOOL

BUGCHK

EXQUOTA

GRPNAM

PRMCEB

PRMGBL

PRMMBX

SHMEM

Disable accounting

Allocate spooled devices

Make bugcheck error log entries

Exceed disk quotas

Insert group logical names in the name table

Create/delete permanent common event flag clusters

Create permanent global sections

Create permanent mailboxes

Create/delete structures in shared memory

System

ALTPRI

AUDIT

OPER

PSWAPM

WORLD

SECURITY

SYSLCK

Set base priority higher than allotment

Generate audit records

Perform operator functions

Change process swap mode

Control any process

Perform security-related functions

Lock systemwide resources

Objects

DIAGNOSE

IMPORT

MOUNT

READALL

SYSGBL

VOLPRO

Diagnose devices

Mount a nonlabeled tape volume

Execute mount volume QIO

Possess read access to all system objects

Create systemwide global sections

Override volume protection

All

BYPASS

CMEXEC

CMKRNL

IMPERSONATE

DOWNGRADE

LOG_IO

PFNMAP

PHY_IO

SETPRV

SHARE

SYSNAM

SYSPRV

UPGRADE

Disregard protection

Change to executive mode

Change to kernel mode

Create detached processes of arbitrary UIC

Write to a lower secrecy object or lower an object's classification

Issue logical I/O requests

Map to specific physical pages

Issue physical I/O requests

Enable any privilege

Access devices allocated to other users

Insert system logical names in the name table

Access objects through the system protection field

Write to a higher integrity object or raise an object's integrity level

8.7.2. Suggested Privilege Allocations

Appendix A lists all user privileges and includes recommendations on when to grant them. When allocating user privileges, be conservative.

The summary guidelines in Table 8.3 indicate the minimum privilege requirements for common classes of system users.
Table 8.3. Minimum Privileges for System Users

Type of User

Minimum Privileges

General

TMPMBX, NETMBX

Operator

OPER

Group manager

GROUP, GRPPRV

System manager/administrator

SYSPRV, OPER, SYSNAM, CMKRNL?

Security administrator

SECURITY, AUDIT, READALL

8.7.3. Limiting User Privileges

Granting privileges allows users those privileges until you remove them. To avoid such blanket permission, you may want to grant privileges on an as-needed basis. For example, certain users may need to run a program requiring one of the more powerful privileges. You can install the program with the necessary privilege by using the Install utility (INSTALL). Section 8.7.4 discusses installing privileged images in more detail.

An alternative to granting blanket privileges is to set up emergency or specialized privileged accounts. Users would log in to these privileged accounts only to perform specific functions. You have two options with this technique:
  • Establish a limited group of users who know about the account and are informed how to use it.

  • Create two accounts for the user, giving the privileges to one account but not to the other. In this case, the user would have the same UIC and the same default directory in each account. (This is the only case where VSI recommends shared UICs, because there is still only one actual user.) If you decide to adopt this dual account practice, avoid obvious user names that reveal which account is the privileged account.

With both options, you can place special restrictions on the privileged account, such as long passwords, brief password lifetimes, restricted hours, and limited modes of operation (no dialup, network, remote, or batch logins). In addition, limited account durations would force frequent consideration of privilege requirements.

Yet another alternative is to use protected subsystems, which are described in Chapter 14, and thereby eliminate the need for any system privileges.

8.7.4. Installing Images with Privilege

A user cannot execute an image that requires a privilege the user does not possess unless the image is installed as a known image with the privilege in question. (See the VSI OpenVMS System Management Utilities Reference Manual for instructions on installing known images.) Execution of a known image with privileges grants those privileges to the user process executing the image for the duration of the image's execution. Thus, you should install images with amplified privileges (other than the normal VSI-supplied configuration) only after ensuring that the privileges are required by the image's function and that the image operates safely. Also consider restricting access to the image to a selected set of users.

Images installed with privileges are activated with all amplified privileges enabled. For maximum safety, images designed to run with amplified privilege should use the $SETPRV system service to disable all amplified privileges immediately on activation, and enable them only when they are needed.

Following is an example of installing an image with privilege. The System Dump Analyzer utility (SDA) requires CMKRNL privilege to analyze the running system.
  1. Install SDA.EXE with the CMKRNL privilege, as follows:
    $ INSTALL SDA.EXE /PRIVILEGED=CMKRNL
  2. Place an ACL on SDA.EXE, and also set the UIC-based protection to deny all access to the world category of users, as follows:
    $ SET SECURITY/ACL=(IDENTIFIER=SDA,ACCESS=EXECUTE)-
    _$ SYS$SYSTEM:SDA.EXE
    $ SET SECURITY/PROTECTION=(WORLD) SYS$SYSTEM:SDA.EXE
  3. Use the AUTHORIZE command to confirm that the users who hold the SDA identifier are those intended to run the program. If necessary, make adjustments to this list of users.

    Note

    All images that you install with privilege must be linked with the /NOTRACEBACK qualifier to prevent online debugging and traceback.

    VSI ensures that all system programs that are supplied with the operating system (such as the SDA) are linked with the /NOTRACEBACK qualifier to prevent online debugging or traceback.

8.7.5. Restricting Command Output

Some DCL commands behave differently depending on the privileges that the user holds.

For example, unless a user holds the GROUP or WORLD privilege, the SHOW PROCESS command limits the display of process information to the user's process. A user with GROUP privilege can display other processes in the user's UIC group; a user with WORLD privilege can display any process on the system.

8.8. Setting Default Protection and Ownership

After designing user groups and identifiers, you need to address which protected objects your users need permission to access and which ones can be unrestricted. Become familiar with the default protection of new objects, shown in Chapter 5, and when necessary modify the defaults, as shown in the following sections.

The procedure for setting up object protection and ownership defaults varies, depending on whether the object is a file or another class of protected object.

8.8.1. Controlling File Access

As Section 5.4.5 explains, there are four possible areas where you can specify protection defaults that would affect the user. In order of increasing influence, they are as follows:
  • The system parameter RMS_FILEPROT sets the systemwide default for file protection. You can change the value of RMS_FILEPROT with AUTOGEN. However, the effectiveness of this value may be overridden by any of the following defaults.

  • The DCL command SET PROTECTION/DEFAULT can specify the file protection placed on files created or modified by the user during the terminal session. While the command typically appears in the user's login command procedure, the user can also enter this command at any time during a session to override the value set by a previous SET PROTECTION/DEFAULT command. The SET PROTECTION/DEFAULT command negates the influence of the systemwide protection for this user.

  • The default protection for the specific directory can be specified in an ACL applied to the directory. If a Default Protection ACE exists for the directory, all new files added to the directory, including subdirectories and their files, are subject to this protection code. This code overrides the systemwide default and the user-specified default (if any).

  • In special cases where the file being created is not owned by the user identification code (UIC) of the process creating the file (for example, when a directory is owned by a resource identifier), the default protection for the new file can be modified by a Creator ACE within the directory's ACL. Refer to Section 5.4.5 for a discussion of the Creator ACE.

Also consider the protection imposed on the volume through the DCL command SET VOLUME/PROTECTION. This protection code, if specified, prevents a user from accessing any part of the volume, regardless of the protection code on the directory or the file. If no volume protection is specified with the SET VOLUME command, the volume is accessible to all users.

The assignment of file ownership affects the outcome of any protection check. The operational effect of this combined protection structure is depicted in Figure 8.1.

Figure 8.1. Flowchart of File Creation
Flowchart of File CreationFlowchart of File CreationFlowchart of File Creation

8.8.1.1. Adjusting Protection Defaults

You may want to make adjustments to control default behavior. The systemwide default protection code specified by the system parameter RMS_FILE PROT sets the user's default protection to the following:
(S:RWED,O:RWED,G:RE,W)
Assume that the volume protection has been set by the operator to the following:
(S:RWED,O:RWED,G:R,W)
The file protection on the directory [PROJECT] has been set to the following:
(S:RWED,O:RW,G:R,W)
If all the files created in the subdirectory [PROJECT.DIARY] demand more protection, you, or any user who has control access to the directory, could define a specific default protection code for this specific directory with an ACL consisting of a Default Protection ACE, as follows:
(DEFAULT_PROTECTION,S:RWED,O:RWED,G,W)
The following DCL command would provide the desired default protection:
$ SET SECURITY/ACL=(DEFAULT_PROTECTION,S:RWED,O:RWED)-
_$ [PROJECT]DIARY.DIR
Once this ACE is placed on the directory file, files created or modified in the directory are subject to the default protection code. Because these protection codes are only defaults, a user who has control access to a file in the directory can include a specific protection code as a replacement for the default value on the file by using the following DCL commands:
  • SET SECURITY/PROTECTION

  • COPY/PROTECTION

  • APPEND/PROTECTION

  • CREATE/PROTECTION

Once the default protection code is replaced, the new code becomes the default and is propagated to subsequent versions of the file.

If you provide a special login command procedure for some of your users, you may want to supplement the systemwide default process protection specified by the system parameter RMS_FILEPROT for this group of users. Add the SET PROTECTION/DEFAULT command to the login command procedure to specify the default process protection, as follows:
SET PROTECTION=(S:RWED,O:RWED,G,W)/DEFAULT

Files created in users' directories receive this default protection code unless explicitly overridden.

8.8.1.2. Setting Defaults for a Directory Owned by a Resource Identifier

To allow for more flexible data management as well as more accurate accounting of disk space, you can set up a directory that is owned by a resource identifier and rely on ACLs to control access to the directory and to files created within it.

The ACL can limit file access to all project members holding the project identifier. To achieve this kind of access restriction, you add an Identifier ACE to define the group's access to files. A second Identifier ACE is added that duplicates the first but holds the Default attribute. It is the Default attribute that ensures the ACE is copied to all files created within the directory. Sometimes a third ACE is necessary—a Default Protection ACE, depending on the default protection code for the directory. A Default Protection ACE establishes the protection code for the directory's files. (As Section 4.3 explains, if an ACL denies access to a file, it is still possible to gain access through a protection code.)

In addition to limiting the group's access to files, an ACL can control the type of access users have to files that they have created within the common directory. Because the file is created in the resource identifier's directory, the resource identifier owns the file. For users to access files they have created, the operating system normally gives control access to the file's creator plus the access specified in the owner field of the protection code. However, you can modify this behavior by adding a Creator ACE to the directory's ACL. A Creator ACE defines the type of access users have to files they have created in the project's directory.

8.8.1.2.1. Setting Up the Resource Identifier
A security administrator used the following command sequence to set up the project identifier PROJECTX and grant it to members of the project. Notice that the identifier is added to the rights database with the resource identifier, and it is also granted to users with the resource identifier. The project identifier needs to carry the Resource attribute so it can own disk space.
$ RUN SYS$SYSTEM:AUTHORIZE
UAF> ADD/IDENTIFIER PROJECTX /ATTRIBUTES=RESOURCE

UAF> GRANT/IDENTIFIER PROJECTX user1 /ATTRIBUTES=RESOURCE
UAF> GRANT/IDENTIFIER PROJECTX user2 /ATTRIBUTES=RESOURCE
  .
  .
  .
8.8.1.2.2. Setting Up the Directory of a Resource Identifier

When a project- or department-specific identifier is the owner of a directory, the space used by files created in the directory can be charged to the appropriate department or project rather than to the individual who creates them. When users work on multiple projects, they can charge their disk space requirements to the related project rather than to their personal accounts.

In setting up a directory for a resource identifier, you first create the disk quota authorization for the project identifier. For example, the following command invokes the System Management utility (SYSMAN) and assigns the identifier PROJECTX 2000 blocks of disk quota with 200 blocks of overdraft:
$ RUN SYS$SYSTEM:SYSMAN
SYSMAN> DISKQUOTA ADD PROJECTX /PERMQUOTA=2000 /OVERDRAFT=200
After setting up the disk quota, you create the project directory. For example, the following DCL command creates the project directory [PROJECTX] and establishes the identifier PROJECTX as its owner:
$ CREATE/DIRECTORY [PROJECTX] /OWNER=[PROJECTX]
8.8.1.2.3. Setting Up the ACL
In setting up the directory [PROJECTX], you use an ACL to provide file access to project members. The following example shows how several ACEs are used to define access:
$ SET SECURITY [PROJECTX] /ACL= (-
_$ (DEFAULT_PROTECTION,S:RWED,O:RWED,G,W),- 1
_$ (IDENTIFIER=PROJECTX,ACCESS=READ+WRITE+EXECUTE),- 2
_$ (IDENTIFIER=PROJECTX,OPTIONS=DEFAULT,ACCESS=READ+WRITE+EXECUTE),- 3
_$ (CREATOR,ACCESS=READ+WRITE+EXECUTE+DELETE)) 4

1

The Default Protection ACE sets up a protection code for files created within the directory. The ACE denies access to group and world users.

2

The first Identifier ACE gives holders of the PROJECTX identifier read, write, and execute access to the directory.

3

The second Identifier ACE guarantees that all files created in the directory will carry the first Identifier ACE.

4

The Creator ACE specifies that a user who creates a file in the PROJECTX directory will receive read, write, execute, and delete access to it.

Thus, when project member Crandall creates the file SEPTEMBER-REPORTS.TXT in the [PROJECTX] directory, the file receives the following security profile:
$ SHOW SECURITY/CLASS=FILE [PROJECTX]SEPTEMBER-REPORTS.TXT

SEPTEMBER-REPORTS.TXT object of class FILE
     Owner: [PROJECTX]
     Protection: (System: RWED, Owner: RWED, Group, World)
     Access Control List:
          (IDENTIFIER=CRANDALL,ACCESS=READ+WRITE+EXECUTE+DELETE)
          (IDENTIFIER=PROJECTX,ACCESS=READ+WRITE+EXECUTE)

Project members are not allowed to delete (or control) files created by others; however, the Creator ACE gives them delete access to files they have created.

Without a Creator ACE, project members each have complete access to files they have created in the directory. For example, Crandall would receive the following access to files created in the project directories:
$ SHOW SECURITY/CLASS=FILE [PROJECTX]SEPTEMBER-REPORTS.TXT

SEPTEMBER-REPORTS.TXT object of class FILE
     Owner: [CRANDALL]
     Protection: (System: RWED, Owner: RWED, Group, World)
     Access Control List:
          (IDENTIFIER=CRANDALL,OPTIONS=NOPROPAGATE,ACCESS=READ+WRITE+EXECUTE+DELETE+CONTROL)
          (IDENTIFIER=PROJECTX,ACCESS=READ+WRITE+EXECUTE)

To negate this behavior, you can add a Creator ACE to the ACL that specifies ACCESS=NONE.

8.8.2. Setting Defaults for Objects Other Than Files

With the exception of files and pseudo-terminal (FT) devices, all classes of protected objects offer one or more template profiles that provide security elements for new objects. You can thus use a single mechanism to establish the default protection code, ACL, and ownership elements for objects. The operating system always stores these values so they are available from one system startup to the next. The SHOW SECURITY command displays the current default values for your particular site. Refer to Chapter 5 for a listing of the operating system's default values.

The operating system generates the security profiles of new objects from data stored by security class objects. These objects are all logical constructs used to keep track of such class elements as the valid access types, the templates, and the types of auditing that have been enabled. As Figure 8.2 shows, every class of protected object has a member in the security class. All members have a security profile template, except for files, which have their own rules.

Figure 8.2. Security Class Object
Security Class Object

8.8.2.1. Displaying Class Defaults

To display any class template, use the SHOW SECURITY/CLASS=SECURITY_CLASS command. The following command, for example, displays templates available for logical name tables. The logical name table object has the following three templates:
$ SHOW SECURITY/CLASS=SECURITY_CLASS LOGICAL_NAME_TABLE
  .
  .
  .
      Template: GROUP
      Owner: [TTSY,SYSTEM]
      Protection: (System: RWCD, Owner: R, Group: R, World:R)
      Access Control List: <empty>

      Template: JOB
      Owner: [TTSY,SYSTEM]
      Protection: (System: RWCD, Owner: RWCD, Group, World)
      Access Control List: <empty>

      Template: DEFAULT
      Owner: [TTSY,SYSTEM]
      Protection: (System: RW, Owner: RW, Group, World)
      Access Control List: <empty>
All objects in the security class are protected in the same manner as other objects. For this reason, any SHOW SECURITY display of a security class object begins with the security profile for the object itself. The following display shows a profile for the logical name table object in the security class. The object is owned by the system, and its protection code allows read access to any user category but allows write access only to system and owner categories.
$ SHOW SECURITY/CLASS=SECURITY_CLASS LOGICAL_NAME_TABLE

LOGICAL_NAME_TABLE object of class SECURITY_CLASS
     Owner: [SYSTEM]
     Protection: (System: RW, Owner: RW, Group: R, World: R)
     Access Control List: <empty>

8.8.2.2. Modifying Class Templates

Security administrators and users with control access to a security class object can modify the elements of a given template with the following command:
SET SECURITY/CLASS=SECURITY_CLASS/PROFILE=TEMPLATE=template-name
The following command modifies the MAILBOX template for the device class. It changes the template values from a protection of S:RWPL,O:RWPL,G:RWPL,W:RWPL to a protection that disallows group and world access.
$ SET SECURITY/CLASS=SECURITY_CLASS/TEMPLATE=MAILBOX -
_$ /PROTECTION=(S:RWPL,ORWPL,G,W) DEVICE
The operating system applies this value to all new mailboxes. To change the protection for each existing mailbox, enter an explicit SET SECURITY command for each existing mailbox. For example:
$ SET SECURITY/CLASS=DEVICE -
_$ /PROTECTION=(S:RWPL,ORWPL,G,W) mailbox_name

The operating system saves the default object protections specified in security templates, so rebooting the system automatically ensures that all objects created after the reboot are created with the new default protections.

Note

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 either modify FTA0 manually, or change the SYSTARTUP_VMS.COM command procedure. For example:
$ SET SECURITY/CLASS=DEVICE/PROTECTION=(S:RWLP,O:RWLP,G:RW,W:R) FTA0:

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.

The DCL command SHOW SECURITY displays all available templates with the site values. Chapter 5 lists the default system values.

8.9. Added Protection for System Data and Resources

This section describes additional ways to restrict the data and resources available to users.

8.9.1. Precautions to Take When Installing New Software

When you install new software, you must address several security concerns. You want to ensure that you are not admitting software that will in any way corrupt or undermine your usual security precautions. You must also consider whether to install the software with any privileges. This section discusses the security aspects of installing new software.

8.9.1.1. Potentially Harmful Programs

New software can contain programs that are potentially harmful to your system. These programs, called Trojan horse programs, are designed to do damage and frequently include features that do the following:
  • Pass privileges of the person running the program back to the author of the program

  • Allow unauthorized access to the system

  • Change protection of system files

  • Patch the system (add special software to the operating system)

  • Create jobs that scan for easily guessed passwords

To protect your system from this type of intrusion, always buy software from reputable sources. When training new users, stress the importance of avoiding use of software from an unknown source.

Another risk to programs and directories is known as the virus. While Trojan horse software must rely on the innocent user to unwittingly accept the damaging software by using it, the virus requires no user cooperation. It is a program that takes advantage of faulty file protection, working its way through your system and modifying command procedures and executable programs. By modifying command procedures, it can propagate by making use of user access rights and privileges.

Viruses are less of a problem in the OpenVMS environment than in an environment of personal computers. The OpenVMS protection features and the environment's larger scale and diversity make virus attacks more difficult. However, no environment that permits the sharing of software and data is immune from virus attacks.

The user's login command procedure is a prime target for this type of security breach. Login command procedures generally contain easily modified DCL commands and are executed regularly.

ACLs are also targets. File protection designed with users sharing access privileges allows this type of program to run through many users' programs, acquiring new privileges along the way.

Well-designed file protection is critical for protection from this type of security breach. Make sure that likely targets cannot be modified by users. For example, set up file protection so that your login command procedure permits at most read access to all other users. Also make sure the directory containing the login command procedure permits write access only to users in the system and owner categories.

Because most damage occurs when programs like these reach a target account with privileges, users with privileges should be especially cautious with the protection of their root directory, executable files, and command procedures. To deter Trojan horse attacks, users should never execute a command procedure or run an image in a privileged account without inspecting the command procedure or the image's sources. Application images should be rebuilt from source to ensure that the binary image reflects the accompanying source.

8.9.1.2. Installing Programs with Privilege

Some software requires privilege to run. You can extend the privilege to all users you expect will need to run the software, or you can install the program with the required privileges. When you install privileged software, you allow users to execute it whether or not they personally possess the required privilege. In effect, you extend the privilege to the process while it runs the software. While this offers some advantages, it also introduces several security-related dangers. Section 8.7 describes these options in greater detail.

8.9.2. Protecting System Files

Even on the most open system, you will want protection for the system software. Normally, VSI delivers system programs and databases with adequate UIC protection. However, if for any reason you are dissatisfied with the default protection, you can change it with the techniques outlined in Chapter 4, provided you have the necessary SYSPRV privilege. You might also add an ACL to any file that you decide needs additional protection.

You can obtain a full listing of system files from the system manager's account during an OpenVMS installation with the following DCL command:
$ DIRECTORY/SECURITY/OUTPUT=SYSTEM_FILES.LIS SYS$SYSROOT:[*...]

VSI recommends you generate such a listing and store it for reference. Regularly compare these values with current system file protection to ensure that no tampering has occurred. (The DCL commands DIRECTORY/SECURITY/OUTPUT and DIFFERENCES facilitate such checks.)

On Alpha systems, you can obtain a listing of system files and their protections from the read-only compact disc distribution media. Your OpenVMS software should have this set of protection codes following a correct installation.

On VAX systems, refer to Appendix B for a listing of system files and their protections. Your OpenVMS software should have this set of protection codes following a correct installation.

Table 8.4 provides a summary of DCL commands you use to set up and display file protection; these commands are described in the VSI OpenVMS DCL Dictionary.
Table 8.4. DCL Commands Used to Protect Files

Command

Function

DIRECTORY/ACL

Displays the ACL for the file

DIRECTORY/OWNER

Displays the file owner's UIC

DIRECTORY/PROTECTION

Displays the file's protection code

DIRECTORY/SECURITY

Combines and displays file information produced by DIRECTORY/ACL, DIRECTORY/OWNER, and DIRECTORY/PROTECTION

EDIT/ACL

Invokes the access control list editor (ACL editor)

SET PROTECTION/DEFAULT

Establishes the default protection to be applied to all files subsequently created

SET SECURITY

Modifies the security profile of any object: the owner, protection code, and ACL

SHOW SECURITY

Displays the ownership, UIC protection code, and ACL of a protected object

The OpenVMS installation procedure does not initially install MAIL.EXE with any privileges (because MAIL.EXE does not require privileges to perform its functions). Prior versions of the OpenVMS operating system did include mechanisms that allowed MAIL.EXE to check, ignore, grant, or override certain privileges that a system manager might assign when reinstalling MAIL.EXE. Because these regulatory mechanisms sometimes created unexpected or undesirable conditions, they have been removed.

Caution

If you reinstall MAIL.EXE with certain privileges, you must carefully consider possible ramifications, including the potential for security breaches. For example, because MAIL.EXE confers its privileges on any user who invokes the Mail utility, that user will inherit those privileges if the user creates a subprocess from within Mail by specifying the SPAWN command.

As indicated, VSI provides default protection for the system programs that it provides. However, if you have a special requirement, you might examine the potential of ACLs for your needs. For example, you might use ACLs to restrict the use of system programs such as compilers. (Any number of considerations might prompt this action, ranging from performance to licensing issues.)

You might also ask if there are cases where you do not want some or all of your users to be able to initialize media. If there are, you can put an ACL to good use on the system program SYS$SYSTEM:INIT.EXE. Ensure that you grant no access to the world category in the UIC-based protection code. Then create an ACL for the file that grants access to specific users.

Similarly, if a department in your company has paid for a license to a software product, you may want to make that software available to them but not to others. Ensure that the world category receives no access through the standard UIC-based protection code, and create an entry in the ACL for that file that allows access through the department's identifier.

You may also find that ACL protection is relevant to protect your applications databases, limiting the access to certain users or to protected subsystems.

8.9.3. Restricting DCL Command Usage

There are several ways that you can affect the use of DCL commands by your users. Among them are the following:
  • Impose ACLs on the system program files in the directories SYS$SYSROOT:[SYSEXE] and SYS$SYSROOT:[SYSLIB].

  • Set the AUTHORIZE flag DISIMAGE to prevent use of the MCR or the RUN command. This prevents users from executing system or user-written images or from executing images defined as foreign commands. Because the DISIMAGE flag is enforced by the DCL command language interpreter (CLI), you must ensure that the account for which the DISIMAGE flag is set has access to the DCL CLI only. Use the DISIMAGE flag in conjunction with the AUTHORIZE flag DEFCLI or within a restricted account. (Setting the RESTRICTED flag for an account implicitly sets the DEFCLI flag.)

  • Remove or modify DCL command definitions, and rebuild the DCL tables. (The VSI OpenVMS System Management Utilities Reference Manual describes how to create command definitions.) Use the /CLITABLES qualifier in the user's UAF record to specify the modified tables. Also specify /FLAGS=DEFCLI to ensure that the user can log in only with the specified command language interpreter (CLI) and tables. Protect the original DCL tables from unauthorized access by imposing ACLs on the system program files in the directories SYS$SYSROOT:[SYSEXE] and SYS$SYSROOT:[SYSLIB]. In particular, protect SYS$LIBRARY:DCLTABLES.EXE and SYS$SYSTEM:CDU.EXE.

8.9.4. Encrypting Files

File encryption refers to the process of applying an algorithm to data to conceal its content. Decryption reverses the operation and converts encoded information back to its original content. If you need to copy proprietary software onto media for removal to another site, you might use file encryption. The software on the media is useless without the correct decryption code.

Different file encryption systems, both software and hardware, are available. Consult your VSI support channel for information on which products are available in your country.

8.9.5. Protecting Disks

Disk scavenging is the process of reading magnetic imprints of data after deletion of the file header following a purge or delete operation. (When users delete files from the system, only the file header is deleted.) Until the data is overwritten, it is a potential target for disk scavenging. Sites with medium or high security needs should be concerned about this procedure.

After establishing overall security features, restrict access to disks containing valuable information by using UIC-based volume protection. Because disk scavenging is frequently performed by authorized users, consider implementing erasure patterns and high-water marking, as described in the following sections.

8.9.5.1. Erasing Techniques

There are several ways to implement erasing of disks.
  • The inclusion of the /ERASE qualifier with the DELETE or the PURGE command causes the system to write an erasure pattern of zeros over the entire file location when you delete or purge that file. You can encourage users to use this qualifier voluntarily or make inclusion automatic by including the following command definitions in the system login command procedure (usually SYS$MANAGER:SYLOGIN.COM):
    DEL*ETE :== "DELETE/ERASE" PUR*GE :== "PURGE/ERASE"

    However, any user can bypass these definitions by adding the /NOERASE qualifier to the DELETE or the PURGE command.

  • To guarantee erase-on-delete, turn on the feature for the entire volume by using the DCL command SET VOLUME/ERASE_ON_DELETE. When files are deleted, this command overwrites all files on the volume with the erasure pattern of zeros.

  • To completely erase the volume and enable erase-on-delete for the volume at volume initialization, use the DCL command INITIALIZE/ERASE.

    By default, when erase-on-delete is enabled, the operating system writes a default data security erase (DSE) pattern of zeros, applied during a single write operation over the area. If you feel that the default pattern of zeros or the single rather than multiple number of erasures does not suit your requirements, you can use the $ERAPAT (Get Security Erase Pattern) system service to write a customized erasure pattern. See the description of $ERAPAT in the VSI OpenVMS Utility Routines Manual for more information.

For sites with high-level security requirements, a random pattern is preferable to a fixed pattern. The technology is already available that can detect and use faint residual magnetic impressions. Thus, if you conclude there is sufficient danger that a disk might be removed and read using some of this specialized analysis equipment, you may need to rewrite the erasure pattern several times. You can learn how to customize the data security erase pattern to fit your needs by studying the information provided in the file SYS$EXAMPLES:DOD_ERAPAT.MAR.

Employ erasing patterns only on disks where the security needs are the greatest. Erasures are time-consuming and affect system performance.

8.9.5.2. Prevention Through High-Water Marking

High-water marking refers to a technique that tracks the furthest extent to which each file has been written and prohibits user attempts at reading data beyond that point.

The operating system implements true high-water marking for all sequential, exclusively accessed files, such as the set of files output from various text editors, compilers, and linkers, that is, most files a process writes. The high-water mark is updated in the file header whenever the logical end-of-file mark is updated (usually when the file is closed).

For shared files (both indexed and sequential), the operating system uses the principle of erase-on-allocate to achieve a result similar to true high-water marking. When a file is about to be created or extended, the system determines how much disk space (the extent of the file) is required and applies the security erasure pattern of zeros to the areas (extents) it allocates for writing. The file is then written into the area just erased for it. Thus, if any user gains access to the file (including its full extent) and attempts to read the area beyond where the file has been written, only the data security erase pattern is readable.

By default, the operating system turns on high-water marking for all volumes. High-water marking is a deterrent to disk scavenging attempts. However, it does require additional I/O, which affects system performance.

You can turn off high-water marking and erase-on-allocate on a volume-by-volume basis by specifying the DCL command SET VOLUME/NOHIGHWATER_MARKING.

8.9.5.3. Summary of Prevention Techniques

As security administrator, you can apply the following controls to discourage disk scavengers:
  • Provide tight physical security, particularly on those disks with the most valuable information.

  • Provide tight volume protection through UIC-based protection.

  • Encourage the use of the /ERASE qualifier when key files are purged or deleted through user participation or volume enforcement.

  • Permit default high-water marking on your most valuable disks.

8.9.6. Protecting Backup Media

You can guard against data loss or corruption by creating copies of your files, directories, and disks. In case of a problem, you can restore the backup copy and continue your work. Secure media storage and controlled access to media are essential parts of the process. It is best to store backup media off site.

8.9.6.1. Backing Up Disks

Having an effective backup schedule is critical to protect your data. By performing regularly scheduled backup operations, you prevent the loss of accidentally deleted or damaged files.

Refer to the VSI OpenVMS System Management Utilities Reference Manual for information about performing backups and setting up backup schedules. Be aware that the Backup utility (BACKUP) does not implement security policy; you must direct it explicitly. It runs with the security profile of the operator, which can often be privileged.

8.9.6.2. Protecting a Backup Save Set

Limiting access to backup save sets is an important part of system security. The file system treats a backup save set as a single file, whether it is stored on disk or on magnetic tape. Therefore, anyone with access to a save set can read any file in the save set. BACKUP does not check protection on individual files.

To maintain system security, it is crucial that you protect save sets adequately. Assign restrictive protection to save sets on disk and to magnetic tape volumes by using the output save-set qualifiers /BY_OWNER and /PROTECTION. Sufficient protection can prevent nonprivileged users from mounting a save-set volume or from reading files from a save set. You should also take physical security precautions with save sets stored off line by keeping backup media in locked cabinets.

When you write a save set to a Files–11 disk or a sequential disk and do not specify the /PROTECTION qualifier, BACKUP applies the process default protection to the save set. If you specify /PROTECTION, any protection categories that you do not specify default to your default process protection.

Protection information is written to the volume header record of a magnetic tape and applies to all save sets stored on the tape. Therefore, the output save-set qualifiers /BY_OWNER and /PROTECTION are effective on magnetic tape save sets only if you specify the output save-set qualifier /REWIND. This qualifier allows the tape to rewind to its beginning, to write the protection data to the volume header record, and to initialize the tape. If you specify /PROTECTION, any protection categories that you do not specify default to your default process protection. If you do not specify /REWIND with the /PROTECTION and /BY_OWNER qualifiers, the magnetic tape retains its existing protection. However, specifying /REWIND alone results in a magnetic tape without any protection.

The following example illustrates how a directory is backed up to tape:
$ BACKUP
_FROM: [PAYROLL]
_TO: MFA2:KNOX.BCK/LABEL=BANK01 -     1
_$ /REWIND/BY_OWNER_UIC=[030,003] -   2
_$ /TAPE_EXPIRATION=15-JAN-1993 -     3
_$ /PROTECTION=(S:RWE,O:RWED,G:RE,W)  4

1

The contents of the directory [PAYROLL] is copied to file KNOX.BCK on the magnetic tape drive MFA2. The output save-set qualifier /LABEL provides the label BANK01 for the tape.

2

The output save-set qualifier /BY_OWNER assigns an owner UIC of [030,003] to the save set.

3

The output save-set qualifier /TAPE_EXPIRATION assigns an expiration date of January 15, 1993 to the tape.

4

The output save-set qualifier /PROTECTION assigns the owner of the volume read, write, execute, and delete access. System users are assigned read, write, and execute access; group users are assigned read and execute access; world users are assigned no access.

8.9.6.3. Retrieving Files from Backup Save Sets

Anyone who has access to a save set can read any file in the save set. Never give a copy of your backup media to a user; a malicious user could restore the files from the tape or disk and compromise the security of the system.

When a nonprivileged user wants to restore a particular file, do not lend the volume containing the save set. You could give away access to all the files on the volume. The safest way to restore a particular file is to restore the file selectively, as shown in the following example:
$ BACKUP MTA0:JULY.BCK/SELECT=[JONES.TEXTPROC]LASTMONTH.DAT -
_$ [*...]/BY_OWNER=ORIGINAL

The selected file is restored with its original directory, ownership, and protection. In this way, the file system determines if the user is permitted access to the file.

8.9.7. Protecting Terminals

The next sections describe the controls available for restricting the use of terminals.

8.9.7.1. Restricting Terminal Use

Through the device object class template TERMINAL, the operating system sets up terminals to be accessible to the SYSTEM account only. When a user logs in, the operating system transfers ownership from a system UIC to the UIC of the current process.

You can limit logins on specific terminals in the following ways:
  • Assign a system password.

  • Set the terminal to /NOTYPE_AHEAD, making it impossible to log in.

The application of system passwords limits the use of those terminals to users who know the system password.

8.9.7.2. Restricting Application Terminals and Miscellaneous Devices

To make terminals accessible to certain users as application terminals, you may want to change any or all of the device's security characteristics. You can include the DCL command SET SECURITY/CLASS=DEVICE for specific terminals (with appropriate protection codes) in the command procedure SYS$MANAGER:SYSTARTUP_VMS.COM. This DCL command can limit access to any device that is not file structured. You might also place an ACL on the device to limit user access.

8.9.7.3. Configuring Terminal Lines for Modems

When configuring terminal lines for modems, never set the /COMMSYNC qualifier to the DCL command SET TERMINAL (or the TT$M_COMMSYNC characteristic for the TTDRIVER interface) on a line with a modem hookup that is intended for interactive use.

The qualifier disables the modem terminal characteristic that disconnects a user process from the terminal line in case of a modem phone line failure. With the /COMMSYNCH qualifier enabled, the next call on the terminal line could be attached to the previous user's process. The /COMMSYNC qualifier is intended to allow connection of asynchronous printers and other devices to terminal ports by using modem signals as flow control.

Chapter 9. Using Encryption

9.1. Defining Keys

To encrypt or decrypt any file, a key has to be created first.

To define a key, enter the ENCRYPT/CREATE_KEY command:

ENCRYPT /CREATE key-name key-value [ qualifiers ]

where

key-nameis the name of the key.
key-valueis the value you assign to the key.
qualifiersare options that control the format of the key value or where the key is stored.

For AES keys, the /AES qualifier must be added:

$ ENCRYPT /CREATE_KEY keyname "This is my secret key" /AES

This generates an AES key with a key length of 21 characters. You can specify a key of any length as long as it meets the key-length minimum requirement and does not exceed Encrypt’s maximum number of characters (approximately 240). For more information on the /AES qualifier, see the VSI OpenVMS DCL Dictionary.

In order to specify the key algorithm, use the /KEY_ALGORITHM qualifier. The default key algorithm is DESCBC for DES keys and AESCBC128 when the /AES qualifier is used. For more information, see Section 9.2.7.2.

9.1.1. Specifying the Key Name

To specify key-name on the ENCRYPT /CREATE_KEY command line, specify a character string using the following rules:

  • Valid length: 1 to 243 characters.

  • Valid: alphanumeric characters, dollar signs, and underscores.

  • Case sensitive: no.

To help you remember the name, use one that has meaning to you.

Note

Key names beginning with ENCRYPT$ are reserved to OpenVMS.

9.1.2. Specifying the Key Value

To specify key-value on the ENCRYPT /CREATE_KEY command line, use either a text string or a hexadecimal constant, using the following rules:

ASCII text string (default):

  • Length: 8 to 240 characters.

  • The string is not case sensitive.

  • If you use any non-alphanumeric characters, for example, space characters, enclose them in quotation marks.

Example: This command defines a key named HAMLET with character string value (And you yourself shall keep the key of it):

$ ENCRYPT /CREATE_KEY HAMLET
_ Key value: "And you yourself shall keep the key of it"

Hexadecimal constant:

  • Use the /HEXADECIMAL qualifier.

  • Valid characters: 0 to 9, A to F.

  • Valid minimum length: 15 characters.

  • Do not enclose the value in quotation marks.

Example: The following command defines a key named ARCANE with hexadecimal value 2F4A98F46BBC11D:

$ ENCRYPT /CREATE_KEY /HEX ARCANE 2F4A98F46BBC11D 

In addition, when you specify key-value, do not use weak keys. These are key values with a pattern of repeated characters or groups of characters. Using a pattern results in an encrypted form that might be easy for unauthorized users to decrypt. For example, the hexadecimal constant 0101010101010101 and the text string 'abcabcabc' are weak keys.

Using weak keys might produce the following consequences:

  • Security of encrypted data may be at risk.

  • Encryption may be the same as decryption.

Encryption with one weak key followed by encryption with another weak key may result in the original plaintext.

VSI supplies a table of known weak keys. The software checks keys you define against this table and displays an error message when you supply a weak key.

9.1.3. Verifying Key Creation

To verify the successful creation of a key, use the /LOG qualifier. For example, this command reports that the key HAMLET is defined:

$ ENCRYPT /CREATE_KEY /LOG HAMLET
_ Key value: "And you yourself shall keep the key of it"
%ENCRYPT-S-KEYDEF, key defined for key name = HAMLET 

The following example verifies an AES key:

$ ENCRYPT/CREATE MY_KEY "This is a sample ASCII key value" /AES/LOG
%ENCRYPT-S-KEYDEF, key defined for key name = MY_KEY

The key is flagged as an AES key to distinguish it from a DES key.

9.1.4. Specifying Key Storage Tables

When you define a key, it is stored in encrypted form in a key storage table. The key value is stored under the key name. When you encrypt files, the process takes this stored information and does the following:

  • It compresses the key value taken from the key storage table into a key consisting of 8 bytes of binary digits.

  • It ensures the odd parity of each byte by modifying one of two things for each byte:

    • Sign bit, as needed (default)

    • Low bit (bit 0) (if you specify the /HEXADECIMAL qualifier)

  • For text string key values, it converts letters to uppercase, reduces multiple consecutive spaces to one space, removes some punctuation characters, and compresses the key string.

    As a result, you do not have to remember the exact syntax of the key value. For example, if you define a key value with two spaces between each word, you do not have to remember this spacing to specify the key again.

Key storage tables determine which users can access keys. The following key storage tables control user access:

  • Process key storage table (default) --- accessible only to the process that defined the keys within the table.

    If you are defining a key that is intended for use by other processes, specify the appropriate qualifier (/JOB, /GROUP, or /SYSTEM) so that the intended users of the key can access it.

  • Job key storage table — accessible only to processes within the same job tree as the process that defined the keys within the table.

  • Group key storage table — accessible to users in the same UIC group as the process that defined the keys in the table.

  • System storage table — accessible to all system users.

To enter keys into the key storage tables, use the following ENCRYPT /CREATE_KEY qualifiers:

  • /PROCESS (default)

  • /JOB

  • /GROUP (requires GRPNAM or SYSPRV privilege)

  • /SYSTEM (requires SYSPRV privilege)

    Defines a key that anyone working on the system can use to encrypt his or her files. Because the key is stored in encrypted form, they cannot see the value of the key. The key is available for use until the system is rebooted.

    For example, the following command defines a key named SYSMASTER and places it in the system key storage table.

    $ ENCRYPT /CREATE_KEY /SYSTEM SYSMASTER
    _$ Key Value: "The human heart has hidden treasures, in secret kept,
    in silence sealed"

9.1.5. Maintaining Keys

When you encrypt a file, the key you use is like a password to that file. It is important to keep it secret. In addition, ensure that you remember the key value. You need both the key and the value to decrypt the file.

A key stored in the process key storage table lasts for the life span of the process that defined the keys in the table. Like other process-specific structures, the process key storage table disappears when you log out.

Key values that are meaningful to you are the most memorable, but avoid easily guessed choices such as your nickname or the make of your car. Never post a key name or value in your office or store it online. Like operating system passwords, increasing the length of a key value lessens the possibility of discovery.

The DES algorithm requires that a key value has a minimum length of eight non-null characters. To improve the security of the key value, specify more than eight characters.

For the AES algorithm, the minimum required key sizes are as follows:

  • 128-bit mode = 16-byte key

  • 192-bit mode = 24-byte key

  • 256-bit mode = 32-byte key

9.2. Encrypting Files

After you define a key with the ENCRYPT /CREATE_KEY command, use this key to encrypt files. Enter the ENCRYPT command. In addition to the key, specify a plaintext file. The syntax of the ENCRYPT command is as follows:

ENCRYPT file-spec key-name [ qualifiers ]

where

file-specis the plaintext input file specification.
key-nameis the name of the key.
qualifiersare options that control the encryption process or the selection of files you want to encrypt.

The following example shows how to define the key and to encrypt a testfile.txt file with the defined key using AES and DES algorithms:

$ ENCRYPT/CREATE_KEY/AES MY_AES_KEY16 "My AES Key length>16"
$ ENCRYPT testfile.txt MY_AES_KEY16 /DATA_ALGORITHM=AESCBC128
/KEY_ALGORITHM=AESCBC128
$!
$ ENCRYPT/CREATE_KEY/AES MY_AES_KEY24 "TEST My AES Key length>24"
$ ENCRYPT testfile.txt MY_AES_KEY24 /DATA_ALGORITHM=AESCBC192
/KEY_ALGORITHM=AESCBC192
$!
$ ENCRYPT/CREATE_KEY/AES MY_AES_KEY32 "TEST TEST TEST My AES Key length>32"
$ ENCRYPT testfile.txt MY_AES_KEY32 /DATA_ALGORITHM=AESCBC256
/KEY_ALGORITHM=AESCBC256
$!
$ ENCRYPT/CREATE_KEY MY_DES_KEY "This is My DES Key"
$ ENCRYPT testfile.txt MY_DES_KEY

If an AES key is required, the /DATA_ALGORITHM and /KEY_ALGORITHM have to be specified with an AES algorithm.

By default, encryption uses the DESCBC data algorithm, if the /DATA_ALGORITHM qualifier is not specified.

By default, encryption uses the DESCBC key algorithm, if the /KEY_ALGORITHM qualifier is not specified.

9.2.1. Input File Specification

For the plaintext file specified on the ENCRYPT command line, use a file that resides on disk and that is not a directory file.

To specify multiple input files, use wildcard characters in the file specification. To control file selection, specify the appropriate ENCRYPT command qualifiers. Do not use wildcard characters to specify directory files or files containing bad blocks.

9.2.2. Output File Specification

The result of the encryption operation is a ciphertext file. One ciphertext file is created for each input file that is encrypted.

By default, the ENCRYPT command writes each ciphertext file to a separate output file with the same name except that it has a version number one higher than that of the current input file.

To specify an alternate output file specification, use the /OUTPUT qualifier. Specify only the file specification parts that you want to change from the defaults. For example, the following command encrypts all the files in the current directory that match the wildcard file specification *.COM. The /OUTPUT qualifier specifies that any output files created have a file type of .ENC. FRANCISSCOTT is the key used to encrypt the files.

$ ENCRYPT *.COM /OUTPUT=.ENC FRANCISSCOTT

Do not specify a file that already exists. For example, you cannot name the output file NEWS.DAT;2 if NEWS.DAT;2 already exists. However, specifying NEWS.DAT as both the input and output files is valid.

9.2.3. Displaying Processing Information

By default, information about the encryption operation is not displayed. To display information about file encryption operations on SYS$COMMAND, use the /SHOW qualifier. The /SHOW qualifier has the format:

/SHOW=keyword

or

/SHOW=keyword-list

Specify one or more of the following keywords:

  • FILES

  • STATISTICS

9.2.3.1. FILES Keyword

The FILES keyword displays the file specifications of the input and output files. For example, /SHOW=FILES in the following command specifies that each input and output file specification be displayed as it is encrypted.

$ ENCRYPT /SHOW=FILES *.COM FRANCISSCOTT
%ENCRYPT-S-ENCRYPTED, DISK2:[FLYNN]MOVE.COM.2 encrypted to DISK2:[FLYNN]MOVE.COM;3 (8 blocks)
  .
  .
  .

9.2.3.2. STATISTICS Keyword

Use the STATISTICS keyword to display encryption stream statistics after the completion of each file operation. The statistics displayed are:

  • Bytes processed

  • Internal records processed

  • CPU time consumed within the encryption algorithm

The following command specifies that encryption stream statistics be displayed on SYS$COMMAND.

$ ENCRYPT /SHOW=STATISTICS *.COM FRANCISSCOTT
%ENCRYPT-S-STATISTICS, encryption stream statistics:
         Total Records: 65
         Total Bytes: 4083
         Total Time: 00:00:01.63
  .
  .
  .

9.2.4. Specifying Files to Encrypt

To specify multiple input files, use the ENCRYPT command with wildcard characters in the input file specification.

The following ENCRYPT command qualifiers can help you select files:

  • /BACKUP

  • /BEFORE

  • /BY_OWNER

  • /CONFIRM

  • /EXCLUDE

  • /EXPIRED

  • /MODIFIED

  • /SINCE

9.2.4.1. /BACKUP Qualifier

The /BACKUP qualifier selects files for encryption according to the date of their most recent backup. This qualifier is meaningful only when used with either the /BEFORE or the /SINCE qualifier. The /BACKUP qualifier has the format:

/BACKUP /BEFORE[=time]

or

/BACKUP /SINCE[=time]

where

time is an OpenVMS time.

If you do not specify a time, TODAY is used. TODAY is the current day, month, and year at 00:00:00.

The following command selects for encryption all files in the current directory matching the wildcard file specification of *.COM that had backup copies made before 00:00:00 15-APR-2009.

$ ENCRYPT /BACKUP /BEFORE=15-APR-2009 *.COM FRANCISSCOTT

Do not use the /BACKUP qualifier with either the /EXPIRED or the /MODIFIED qualifier.

9.2.4.2. /BEFORE Qualifier

The /BEFORE qualifier selects files for encryption that have a creation time before the time specified with the qualifier. The /BEFORE qualifier has the format:

/BEFORE[=time]

where

time is an OpenVMS time.

If you do not specify a time, TODAY is used. TODAY is the current day, month, and year at 00:00:00.

The following command selects for encryption all files in the current directory matching the wildcard file specification of *.COM that were created before 00:00:00 15-APR-2009.

$ ENCRYPT /BEFORE=15-APR-2009 *.COM FRANCISSCOTT

9.2.4.3. /BY_OWNER Qualifier

The /BY_OWNER qualifier allows you to select files for encryption that have a particular owner User Identification Code (UIC). If no UIC is specified with the qualifier, the UIC of the current process is used. The /BY_OWNER qualifier has the format:

/BY_OWNER=uic

where

uic is the UIC of the owner of the file.

The following command selects for encryption all files in the current directory owned by the user whose UIC is [FLYNN] that match the wildcard file specification of *.COM.

$ ENCRYPT /BY_OWNER=[FLYNN] *.COM FRANCISSCOTT

9.2.4.4. /CONFIRM Qualifier

By default, all input files specified on the command line are processed without confirming that those files are selected for encryption. Use the /CONFIRM qualifier if you want a prompt with the name of each file selected for encryption. Your response determines whether or not a particular file is encrypted, as follows:

ResponseMeaning
YESEncrypt the file.
NO or RETURNDo not encrypt the file. This is the default.
QUIT or CTRL/ZDo not encrypt the file or any subsequent files.
ALLEncrypt the file and all subsequent files.

The following command selects for encryption all files in the current directory matching the wildcard file specification of *.COM. Because the /CONFIRM qualifier is specified, the user is prompted on a file-by-file basis to confirm that each file is to be encrypted. Because the prompt is answered in the affirmative for the file MOVE.COM;3, the output file MOVE.COM;4 is created.

$ ENCRYPT /CONFIRM *.COM FRANCISSCOTT
Encrypt DISK2:[FLYNN]MOVE.COM;3 ? [N] YES 

9.2.4.5. /EXCLUDE Qualifier

Use the /EXCLUDE qualifier to exclude one or more files from an encryption operation. If a file matches the file specification provided with the /EXCLUDE qualifier, the file will not be encrypted. The /EXCLUDE qualifier has the format:

/EXCLUDE=(file-spec[,...])

where

file-spec is the name of the file to remain unencrypted.

Wildcard characters are allowed in the file specification. There is no default for the file specification. Because directory files are never encrypted, you need not specify them with the /EXCLUDE qualifier. However, if you do specify /EXCLUDE=*.DIR, you will not get the warning message %ENCRYPT-W-FILNODIR, file encryption of directories is not supported, filename.dir.

The following command selects for encryption all files in the current directory that match the wildcard file specification of *.COM, except LOGIN.COM, which is specified with /EXCLUDE.

$ ENCRYPT /EXCLUDE=LOGIN.COM *.COM FRANCISSCOTT

9.2.4.6. /EXPIRED Qualifier

The /EXPIRED qualifier selects files for encryption according to the dates on which they expire. (The expiration date is set with the SET FILE /EXPIRATION_DATE command.) This qualifier is meaningful only when used with either the /BEFORE or the /SINCE qualifier. The /EXPIRED qualifier has the format:

/EXPIRED /BEFORE[=time]

or

/EXPIRED /SINCE[=time]

where

time is an OpenVMS time.

If you do not specify a time, TODAY is used. TODAY is the current day, month, and year at 00:00:00.

The following command selects for encryption all files in the current directory matching the wildcard file specification of *.COM that expire after 00:00:00 15-APR-2009.

$ ENCRYPT /EXPIRED /SINCE=15-APR-2009 *.COM FRANCISSCOTT

Do not use the /EXPIRED qualifier with either the /BACKUP or the /MODIFIED qualifier.

9.2.4.7. /MODIFIED Qualifier

The /MODIFIED qualifier selects files for encryption according to the dates on which they were last modified. This qualifier is meaningful only when used with either the /BEFORE or the /SINCE qualifier. The /MODIFIED qualifier has the format:

/MODIFIED /BEFORE[=time]

or

/MODIFIED /SINCE[=time]

where

time is an OpenVMS time.

If you do not specify a time, TODAY is used. TODAY is the current day, month, and year at 00:00:00.

The following command selects for encryption all files in the current directory matching the wildcard file specification of *.COM that were modified after 00:00:00 15-APR-2009.

$ ENCRYPT /MODIFIED /SINCE=15-APR-2009 *.COM FRANCISSCOTT

Do not use the /MODIFIED qualifier with either the /BACKUP or the /EXPIRED qualifier.

9.2.4.8. /SINCE Qualifier

The /SINCE qualifier selects for encryption files that have a creation date after the time specified with the qualifier. The /SINCE qualifier has the format:

/SINCE[=time]

where

time is an OpenVMS time.

If you do not specify a time, TODAY is used. TODAY is the current day, month, and year at 00:00:00.

The following command selects for encryption all files in the current directory matching the wildcard file specification of *.COM that were created after 00:00:00 15-APR-2009.

$ ENCRYPT /SINCE=15-APR-2009 *.COM FRANCISSCOTT

9.2.5. Deleting Encrypted Files

By default, when the ENCRYPT software encrypts an input file and writes the resulting output file, the input file is retained. However, do not encrypt a file and then leave the plaintext file online if you are concerned about the security of the file.

You can use the DCL DELETE command with the /ERASE qualifier to remove the contents of the plaintext file from the disk, or you can use the following qualifiers with the ENCRYPT command:

  • /DELETE

  • /ERASE

9.2.5.1. DELETE Qualifier

The /DELETE qualifier deletes the input file after the encryption operation completes and the output file is written and closed. If you have multiple versions of the input file, they are not all deleted. /DELETE acts on only the version of the input file that you encrypted.

To delete the unencrypted input file from the disk, use the /DELETE qualifier. The following command specifies that the SAVEDMAIL.MAI file be encrypted using the TWENTYFIVECENTS encryption key. Because the /DELETE qualifier is specified, the input file is deleted after the encrypted output file is written.

$ ENCRYPT /DELETE SAVEDMAIL.MAI TWENTYFIVECENTS

Note

There may be scenarios when the ENCRYPT/COMPRESS command executes without error, but decryption fails. This can be catastrophic if the /DELETE qualifier is used, deleting the original BACKUP save-set file during the encrypt operation. Therefore, it is recommended not to use /DELETE qualifier along with the /COMPRESS qualifier.

9.2.5.2. /ERASE Qualifier

When you delete or purge a file, the file's header record is destroyed so that the file can no longer be accessed by normal means. The information in the file, however, stays on the disk until it is overwritten. Disk scavenging is a technique used to obtain such file data from a disk. To thwart disk scavenging, use the /ERASE qualifier with the /DELETE qualifier. When you specify /ERASE, the OpenVMS operating system overwrites the location in which the input file was stored with the data security pattern. The data no longer exists.

The following command specifies that after SAVEDMAIL.MAI is encrypted, the input file is erased with the data security pattern before being deleted.

$ ENCRYPT /DELETE /ERASE SAVEDMAIL.MAI TWENTYFIVECENTS

9.2.6. Encryption Algorithms

Files are encrypted using a randomly generated data key. One benefit of this procedure is that two files identical in plaintext form and encrypted with the same command are not identical in their encrypted form.

The Encryption for OpenVMS implementation of DES uses the following modes of the DES algorithm:

  • Cipher Block Chaining (DESCBC)

  • Electronic Code Book (DESECB)

  • Cipher Feedback (DESCFB)

These modes perform the encryption operation differently, as follows:

  • DESCBC (default)

    1. Input is taken in 8-byte blocks.

    2. DESCBC performs an exclusive OR operation (XOR) on each block. (An XOR is a bit-by-bit modulo-2 addition without carrying. For example, the result of performing an XOR on the binary numbers 001 and 111 is 110.)

      The first XOR operation is performed on the first block of input and the initialization vector. (An initialization vector is used to start the chaining of data because there is no ciphertext to affect the encryption of the first block of data.)

    3. The resulting block is encrypted.

    4. The next XOR operation is performed on the resulting block of ciphertext and the next block of plaintext, and so on.

    5. If fewer than 8 bytes are left for the last iteration, the block is padded with bytes of arbitrary value.

    6. Each block of 8 bytes is encrypted under the same key value.

    7. The DESCBC algorithm is used to encrypt the data key and the initialization vector. The encrypted key and initialization vector are stored with the encrypted file. The DESCBC algorithm is also used by default to encrypt the file data.

  • DESECB

    1. Input is taken in 8-byte blocks.

    2. If the input consists of less than 8 bytes, it is padded with nulls.

    3. Each block is processed under the DES algorithm with the same key.

    4. The result is an 8-byte block of output that is independent of all other blocks of output.

  • DESCFB

    1. Input is taken as a series of 1-byte quantities.

    2. They are shifted to the left and concatenated with the results of previous iterations.

    3. DESCFB uses an initialization vector in the first iteration.

    4. Only the exact number of bytes specified in the input are used.

    5. The output byte count equals the input byte count (no padding).

AES algorithm uses the following modes:

  • Cipher block chaining:

    • AESCBC128 (default)

    • AESCBC192

    • AESCBC256

  • Electronic code book:

    • AESECB128

    • AESECB192

    • AESECB256

  • Cipher feedback:

    • AESCFB128

    • AESCFB192

    • AESCFB256

  • Output feedback:

    • AESOFB128

    • AESOFB192

    • AESOFB256

For details about the advantages of each mode, see one of the numerous texts available on this subject.

9.2.7. Encryption Algorithm Qualifiers

You can choose an encryption algorithm for encrypting either the data key or the file data. Figure 9.1 illustrates the relationship of encryption keys and algorithms. The figure shows that:

  • To encrypt the key — use the /KEY_ALGORITHM or /KEY_ALGORITHM=AESmmmkkk qualifier to specify an algorithm other than the default DESCBC or AESCBC128 algorithms.

  • To encrypt the file — use the /DATA_ALGORITHM or /DATA_ALGORITHM=AESmmmkkk qualifier to specify an algorithm other than the default DESCBC or AESCBC128 algorithms.

Here, mmm indicates the mode CBC, ECB, CFB, or OFB; and kkk indicates 128, 192, or 256 bits.

Figure 9.1. Relationship of Keys and Algorithms
Relationship of Keys and Algorithms

The qualifier you use affects the decryption procedure:

  • If you use the /DATA_ALGORITHM qualifier to encrypt, you do NOT need to specify this algorithm when you decrypt.

  • If you use the /KEY_ALGORITHM qualifier to encrypt, you DO need to specify this algorithm when you decrypt.

9.2.7.1. /KEY_ALGORITHM Qualifier

To specify an algorithm other than the default, to encrypt the key and initialization vector, use the /KEY_ALGORITHM qualifier. This qualifier has the format:

/KEY_ALGORITHM={DESCBC (default)|AESmmmkkk

For example, the following command uses the DESCFB algorithm with the TWENTYFIVECENTS key to protect the data key and the initialization vector.

$ ENCRYPT /KEY_ALGORITHM=DESCFB SAVEDMAIL.MAI TWENTYFIVECENTS

You can use /KEY_ALGORITHM=AES as a shortcut for specifying AESCBC128. For example:

$ ENCRYPT file-name key-name /KEY_ALGORITHM=AES

9.2.7.2. /DATA_ALGORITHM Qualifier

To specify an algorithm for encrypting files other than the default, use the /DATA_ALGORITHM qualifier. This qualifier has the format:

/DATA_ALGORITHM={DESCBC (default)|AESmmmkkk

For example, the following command encrypts the SAVEDMAIL.MAI file using the Cipher Feedback mode of the DES algorithm (DESCFB).

$ ENCRYPT /DATA_ALGORITHM=DESCFB SAVEDMAIL.MAI TWENTYFIVECENTS

If you use the default value of DESCBC for the /DATA_ALGORITHM qualifier when encrypting a file, this qualifier is optional for decrypting the file.

You can use /DATA_ALGORITHM=AES as a shortcut for specifying AESCBC128. For example:

$ ENCRYPT file-name key-name /KEY_ALGORITHM=AES /DATA_ALGORITHM=AES

9.2.8. Specifying AES Data Algorithm and AES Key Algorithm

To select an algorithm other than the DESCBC default when encrypting files, Encrypt accepts the data and key algorithm qualifiers with the DCL ENCRYPT command and the key algorithm qualifier with the DECRYPT command.

When encrypting files with AES, specify both /DATA_ ALGORITHM=AESmmmkkk and /KEY_ALGORITHM=AESmmmkkk:

  • mmm defines the AES mode: ECB, CBC, CFB, or OFB

  • kkk defines the key size: 128, 192, or 256 bits (for 16-, 24- or 32-byte keys)

The key must match the key algorithm. An AES key must be used with an AES key algorithm, and a DES key must be used with the DES key algorithm. The data algorithm defaults to DES if the /DATA_ ALGORITHM=AESmmmkkk is not specified for the ENCRYPT command. When using DES keys and KEY_ALGORITHM=DES, the data is protected with a strong algorithm, but the key is not.

Note

The capability of mixing AES with DES keys and data algorithms is disabled and any attempt to mix the algorithms results in an ENCRYPT$_AESMIXDES error condition.

When decrypting files with AES, specify only the /KEY_ ALGORITHM=AESmmmkkk qualifier. The reason for this is that the key algorithm is used to decrypt the random-key record that contains the random key, which is then used to decrypt the data records of the file. Specifying the data algorithm is not necessary and it gives an unrecognized-qualifier error message.

Note

For an encrypt operation, if the /DATA_ALGORITHM=AES is specified without the /KEY_ALGORITHM, an error occurs. The default algorithm DESCBC is used to encrypt the random key record that contains the random key and file information. However, the user key must match the KEY algorithm; if not, an error occurs. For example, consider that the key-name is an AES key name and value. When the key is fetched from the logical name table and then is decrypted with the DES master key, the key decrypts garbage, and the operation fails with the following error message:

%STR-F-FATINTERR, fatal internal error

9.2.9. File Compression

To reduce the size of the plaintext file before encrypting it, use the /COMPRESS qualifier. Data compression can save media space when physically transporting encrypted files and can save time when electronically transporting encrypted files across a network.

Compression efficiency depends on the structure of the data in your file. Evaluate a performance tradeoff when deciding whether or not to use this qualifier. Decryption is generally faster on a compressed file, but encryption takes longer. You might choose to use the /COMPRESS qualifier when the following conditions apply:

  • The file will be decrypted many times.

  • The file is at least 200 disk blocks in size.

The following command compresses the SAVEDMAIL.MAI file before encrypting it.

Note

If you use the /COMPRESS qualifier when encrypting a file, you need not specify this qualifier when decrypting the file. If necessary, the file is automatically decompressed when it is decrypted.

$ ENCRYPT /COMPRESS SAVEDMAIL.MAI TWENTYFIVECENTS

Do not use /DELETE qualifier with /COMPRESS because there may be scenarios when the ENCRYPT/COMPRESS command executes without error, but decryption fails. This can be catastrophic if the /DELETE qualifier is used, deleting the original BACKUP save-set file during the encrypt operation.

9.2.10. Displaying the Version Number

To identify the version of Encryption software running on your system, use the /VERSION qualifier. For example:

$ ENCRYPT /VERSION 
Copyright (c) Compaq 2001, Digital Equipment Corporation. 1978, 1997. All
rights reserved.
Compaq Encryption V1.6)

9.3. Authenticating Files

Authentication is the checking of files to determine whether or not they have been modified.

The ENCRYPT/AUTHENTICATE command detects any modification of either plaintext or ciphertext files. The software calculates a Message Authentication Code (MAC) based on the contents of the files and associates it with one or more files. An additional MAC is created that is based on security settings unless you specifically request that the security MAC not be created. At a later time, when you want to check file integrity, the software recalculates the MACs and then compares the current and stored MACs. Before you use the ENCRYPT /AUTHENTICATE command, complete the process that associates MACs with files.

Note

AES (Advanced Encryption Standard) is not supported with /AUTHENTICATE qualifier.

The ENCRYPT /AUTHENTICATE command has the following syntax:

ENCRYPT /AUTHENTICATE file-spec key-name [qualifiers]

where

file-specis the name of the file you want to check.
key-nameis the name of the key. Specify a 1-to-243-character string.
qualifiersare options that control the encryption process or the selection of files you want to encrypt.

A summary report on the authentication operation is displayed on SYS$OUTPUT.

The following qualifiers are valid with ENCRYPT /AUTHENTICATE:

  • /[NO]DATABASE[=file-spec]

    Specifies a file in which to store binary MAC values created by using the file contents as input

  • /LOG

    Displays the results of the authentication operation for each file

  • /MULTIPLE_FILES

    Indicates that the file-spec parameter represents a list of file names to be checked

  • /[NO]OUTPUT[=file-spec]

    Specifies a file in which to store readable MAC values

  • /[NO]SECURITY[=file-spec]

    Generates a MAC using the file's security settings: owner, protection settings, and optional ACL, and specifies the file in which to store the binary MAC values.

  • /[NO]UPDATE

    Associates new MAC values with one or more files

In addition, you can use all the file selection qualifiers available to the ENCRYPT command: /BACKUP, /BEFORE, /BY_OWNER, /CONFIRM, /EXCLUDE, /EXPIRED, /MODIFIED, and /SINCE.

The following sections describe how to use the /DATABASE, /LOG, /SECURITY, /OUTPUT, and /UPDATE qualifiers with ENCRYPT /AUTHENTICATE.

9.3.1. Associating MACs with Files

To associate MACs with a file or to replace former MAC values with new MAC values, use the /UPDATE qualifier. The /UPDATE qualifer updates two different MACs created from file contents and from security settings. The following command creates MAC values for all files in the current directory.

$ ENCRYPT /AUTHENTICATE *.* whitehen /UPDATE

%ENCRYPT-I-SUMMARY1,   Summary:   Files successfully authenticated: 0
%ENCRYPT-I-SUMMARY2,              Files failing authentication:  0
%ENCRYPT-I-SUMMARY3,              Files not in database:  3
%ENCRYPT-I-SECSUMM1,   Summary:   Security settings authenticated: 0
%ENCRYPT-I-SECSUMM2,              Security settings failing authentication: 0
%ENCRYPT-I-SECSUMM3,              Security settings not in database: 3

Two sets of summary information are displayed: the first set applies to the MAC values generated from the file contents, the second set applies to the MAC values generated from the security settings. Because this is the first time MACs are associated with these files, none are reported as authenticated (summary message 1 for each set) or as having failed authentication (summary message 2 for each set). The last message in each set reports that no previous MACs were associated with these files.

The MACs are stored in a binary database. Therefore, you cannot specify /NODATABASE or /NOSECURITY with /UPDATE.

9.3.2. Checking Files

With no other qualifiers, the ENCRYPT /AUTHENTICATE command compares previous MACs with current MACs. In addition, the software reports on files with no currently associated MACs.

The following command reports on the status of all the files in the current directory.

$ ENCRYPT /AUTHENTICATE *.* whitehen

%ENCRYPT-I-NOUPDATE, database will not be updated with new authentication codes
%ENCRYPT-I-SUMMARY1, Summary:   Files successfully authenticated: 3
%ENCRYPT-I-SUMMARY2,            Files failing authentication:  0
%ENCRYPT-I-SUMMARY3,            Files not in database:  0
%ENCYRPT-I-SECSUMM1, Summary:   Security settings authenticated: 3
%ENCYRPT-I-SECSUMM2,            Security settings failing authenticated: 0
%ENCYRPT-I-SECSUMM3,            Security settings not in database:0

9.3.3. Specifying a File for MACs Generated from File Contents

A database file stores MAC values in binary format. By default, binary MAC values created from the file contents are stored in SYS$LOGIN:ENCRYPT$MAC.DAT. You can use the /DATABASE qualifier to store the MAC values in an alternate file.

The following command selects an alternate file in which to store the MAC values.

$ ENCRYPT /AUTHENTICATE *.com whitehen /DATABASE=[MACS]MACCHECK.DAT /UPDATE

%ENCRYPT-I-NEWDB,     New authentication code database has been created
%ENCRYPT-I-SUMMARY1,  Summary: Files successfully authenticated: 0
%ENCRYPT-I-SUMMARY2,  Files failing authentication:  0
%ENCRYPT-I-SUMMARY3,  Files not in database:  6

When you specify /NODATABASE, the MAC values are not stored. The next time you use the ENCRYPT /AUTHENTICATE command, the files are treated as new since there are no current MAC values to check.

9.3.4. Specifying a Security MAC File

MAC entries based on security settings are automatically generated and stored in a security database when the /UPDATE qualifier is used. If you do not want to generate a MAC value based on security settings, use the /NOSECURITY qualifier on the ENCRYPT /AUTHENTICATE command line.

The entries in the security database are generated by using the security settings: owner, protection settings, and an ACL if one is associated with the file. By default, security MAC values are stored in the database ENCRYPT$SEC.DAT. You can use the /SECURITY qualifier to store security MAC values in an alternate file.

The following command selects an alternate file in which to store security MAC values.

$ ENCRYPT /AUTHENTICATE *.com seveneleven /SECURITY=SECURITYMAC.DAT /UPDATE

%ENCYRPT-I-NEWSECDB, New authentication security settings database has been created
%ENCRYPT-I-SUMMARY1, Summary:   Files successfully authenticated: 0
%ENCRYPT-I-SUMMARY2,            Files failing authentication: 0
%ENCRYPT-I-SUMMARY3,            Files not in database: 3
%ENCRYPT-I-SECSUMM1, Summary:   Security settings authenticated: 0
%ENCRYPT-I-SECSUMM2,            Security settings failing authentication: 0
%ENCRYPT-I-SECSUMM3,            Security settings not in database: 3

9.3.5. Specifying a Listing File

In addition to a binary MAC database, Encryption stores MAC values and status information in readable form. By default, readable MAC values are stored in SYS$LOGIN:ENCRYPT$MAC.LIS.

To store readable values in an alternate file, use the /OUTPUT qualifier. The file extension defaults to .LIS. For example, this command specifies SYS$LOGIN:08MAC.LIS as the listing file:

$ ENCRYPT /AUTHENTICATE *.*  whitehen /OUTPUT=08MAC

%ENCRYPT-I-NOUPDATE, database will not be updated with new authentication codes
%ENCRYPT-I-SUMMARY1, Summary: Files successfully authenticated: 6
%ENCRYPT-I-SUMMARY2, Files failing authentication:  0
%ENCRYPT-I-SUMMARY3, Files not in database:  0

To display the listing on SYS$OUTPUT, enter:

$ TYPE 08MAC.LIS

File Integrity Report  22-APR-2009 10:50:22.62       Compaq Encryption  V1.6  Page  1
Authentication database: DISK_1:[000000.SCRATCH]ENCRYPT$MAC.DAT;1

File name                           Stored MAC         Current MAC  Status
==================================  =================  ===========  ======
DISK_1[SCRATCH]EXAMPLE.FILE;1       90E70CB4E8E96BBF   (same)
 owner: [1,1]  prot: (RWED, RWED, RWED, )
DISK_1[SCRATCH]PICTURE.SLS;1        FCAD115A72E7934A   (same)
 owner: [1,1]  prot: (RWED, RWED, RWED, )
DISK_1[SCRATCH]RELEASE.TXT;1        11375BD8D504ABB3   (same)
 owner: [1,1]  prot: (RWED, RWED, RWED, )
DISK_1[SCRATCH]RELEASE_NOTES.PS;3   2632027C133A8B5F   (same)
 owner: [1,1]  prot: (RWED, RWED, RWED, )
DISK_1[SCRATCH]SCHEDULE.LIST;3      852D440358FBFF95   (same)
 owner: [1,1]  prot: (RWED, RWED, RWED, )
DISK_1[SCRATCH]WATCH_MAIL.COM;5     B75D00EC4991662C   (same)
 owner: [1,1]  prot: (RWED, RWED, RWED, )

Summary:        Files successfully authenticated: 6
                Files failing authentication: 0
                Files not in database: 0

Summary:        Security settings authenticated: 6
                Security settings failing authentication: 0
                Security settings not in database: 0

To suppress the creation of this listing, use the /NOOUTPUT qualifier.

9.3.6. Logging the Authentication Operation

To display the results of the authentication operation on each file, use the /LOG qualifier. For example, the following command displays the results of each file authentication on your terminal screen.

$ ENCRYPT /AUTHENTICATE /LOG *.* whitehen

%ENCRYPT-I-NOUPDATE, database will not be updated with new authentication codes
%ENCRYPT-S-AUTHMATCH, File DISK_1:[SCRATCH]EXAMPLE.TXT;1 successfully authenticated
%ENCRYPT-S-SECAUTHMATCH, Security settings for DISK_1:[SCRATCH]EXAMPLE.TXT successfully authenticated
%ENCRYPT-S-AUTHMATCH, File DISK_1:[SCRATCH]TEST.TXT;1 successfully authenticated.
%ENCRYPT-S-SECAUTHMATCH, Security settings for DISK_1:[SCRATCH]TEST.TXT successfully authenticated
%ENCRYPT-S-AUTHMATCH, File DISK_1:[SCRATCH]RELEASE.TXT;2 successfully authenticated.
%ENCRYPT-S-SECAUTHMATCH, Security settings for DISK_1:[SCRATCH]RELEASE.TXT successfully authenticated
%ENCRYPT-I-SUMMARY1, Summary:   Files successfully authenticated: 6
%ENCRYPT-I-SUMMARY2,            Files failing authentication:0
%ENCRYPT-I-SUMMARY3,            Files not in database:0

%ENCRYPT-I-SECSUMM1, Summary:   Security settings authenticated: 6
%ENCRYPT-I-SECSUMM2,            Security settings failing authentication:0
%ENCRYPT-I-SECSUMM3,            Security settings not in database:0

9.4. Deleting key definitions

When a key outlives its usefulness, delete it from a key storage table. Enter the ENCRYPT /REMOVE_KEY command and specify the name under which the encrypted key value was stored in the key table. The key name is the character string previously defined with an ENCRYPT /CREATE_KEY command.

The ENCRYPT /REMOVE_KEY command has the following format:

ENCRYPT /REMOVE_KEY key-name [qualifiers]

By default, the ENCRYPT /REMOVE_KEY command deletes the key definition from the process key storage table. Logging out a process also removes a key definition from the process key storage table.

To remove a key definition from the job, group, or system storage table, specify the /JOB, /GROUP, or /SYSTEM qualifier with the ENCRYPT /REMOVE_KEY command. Just as you need privileges to create group or system keys, you need privileges to delete them.

For example, the following command deletes the HAMLET key from the system key storage table:

$ DECRYPT /REMOVE_KEY HAMLET /SYSTEM

To verify key removal, use the /LOG qualifier with the ENCRYPT /REMOVE_KEY command. The following command reports that the key HAMLET is removed:

$ ENCRYPT /REMOVE_KEY HAMLET /SYSTEM /LOG
%ENCRYPT-S-KEYDEL, key deleted for key name = HAMLET

9.5. Decrypting files

To gain access to the data in an encrypted file, decrypt the file using the DECRYPT command. Follow these steps:

  1. Specify the same key used to encrypt the file.

    See if you need to redefine the key using the ENCRYPT /CREATE_KEY command. For example, if the key was in the process key storage table and the process logged out, the key is no longer defined.

  2. Specify the algorithm with the /KEY_ALGORITHM qualifier, if you did not encrypt the file with the default algorithm.

DECRYPT file-spec key-name [qualifiers]

where

file-specis the name of the file.
key-nameis the name of the key.
qualifiersare options that control the decryption process or the selection of files you want to decrypt.

See the following example:

$ ENCRYPT/CREATE_KEY/AES MY_AES_KEY16 "My AES Key length>16"
$ ENCRYPT testfile.txt MY_AES_KEY16 /DATA_ALGORITHM=AESCBC128
/KEY_ALGORITHM=AESCBC128
$ DECRYPT testfile.txt MY_AES_KEY16 /KEY_ALGORITHM=AESCBC128
$!
$ ENCRYPT/CREATE_KEY/AES MY_AES_KEY24 "TEST My AES Key length>24"
$ ENCRYPT testfile.txt MY_AES_KEY24 /DATA_ALGORITHM=AESCBC192
/KEY_ALGORITHM=AESCBC192
$ DECRYPT testfile.txt MY_AES_KEY24 /KEY_ALGORITHM=AESCBC192
$!
$ ENCRYPT/CREATE_KEY/AES MY_AES_KEY32 "TEST TEST TEST My AES Key length>32"
$ ENCRYPT testfile.txt MY_AES_KEY32 /DATA_ALGORITHM=AESCBC256
/KEY_ALGORITHM=AESCBC256
$ DECRYPT testfile.txt MY_AES_KEY32 /KEY_ALGORITHM=AESCBC256
$!
$ ENCRYPT/CREATE_KEY MY_DES_KEY "This is My DES Key"
$ ENCRYPT testfile.txt MY_DES_KEY
$ DECRYPT testfile.txt MY_DES_KEY

9.5.1. Input File Specification

For the ciphertext file, which is the file to be decrypted, specify a file that resides on disk and that is not a directory file.

To specify multiple input files to the DECRYPT command, use wildcard characters in the file specification. To control file selection, specify the appropriate DECRYPT command qualifiers. Do not use wildcard characters to specify directory files or files containing bad blocks.

9.5.2. Output File Specification

The result of the decryption operation is a plaintext file. One plaintext file is created for each input file that is decrypted. By default, the DECRYPT command writes each plaintext file to a separate output file with a file specification that defaults to the input file specification with a version number that is one higher than that of the input file.

You can specify an alternate output file specification with the /OUTPUT qualifier. When specifying the /OUTPUT qualifier, you specify those parts of the file specification that you want to be different from the defaults. You do not need to specify an entire file specification; any fields omitted in the file specification default to the input file specification.

For example, the following DCL command selects for decryption all files in the current directory matching the wildcard file specification of *.ENC. The /OUTPUT qualifier specifies that any output files created have a file type of COM.

$ DECRYPT *.ENC/OUTPUT=.COM FRANCISSCOTT

9.5.3. Displaying Processing Information

By default, information about the decryption operation is not displayed on SYS$COMMAND. To display this information, use the /SHOW qualifier. The /SHOW qualifier has the format:

/SHOW=keyword

or

/SHOW=keyword-list

Specify one or more of the following keywords:

  • FILES

  • STATISTICS

9.5.3.1. FILES Keyword

Use the FILES keyword to display the input and output file specifications as decryption proceeds. For example, /SHOW=FILES in the following command specifies that each input and output file specification be displayed as it is decrypted.

$ DECRYPT /SHOW=FILES *.COM FRANCISSCOTT
%ENCRYPT-S-DECRYPTED, DISK2:[FLYNN]MOVE.COM.3 decrypted to
  DISK2:[FLYNN]MOVE.COM;4 (8 blocks)
  .
  .
  .

9.5.3.2. STATISTICS Keyword

Use the STATISTICS keyword to display encryption stream statistics after the completion of each file decryption operation. The statistics displayed are:

  • Bytes processed

  • Internal records processed

  • CPU time consumed within the encryption algorithm

The following command specifies that the decryption stream statistics be displayed on SYS$COMMAND.

$ DECRYPT /SHOW=STATISTICS *.COM FRANCISSCOTT
%ENCRYPT-S-STATISTICS, encryption stream statistics:
         Total Records: 65
         Total Bytes: 4083
         Total Time: 00:00:00:01.63
  .
  .
  .

9.5.4. Specifying Files to Decrypt

You can use the DECRYPT command to specify multiple input files by using wildcard characters in the input file specification. The command also provides the following qualifiers for selecting files:

  • /BACKUP

  • /BEFORE

  • /BY_OWNER

  • /CONFIRM

  • /EXCLUDE

  • /EXPIRED

  • /MODIFIED

  • /SINCE

The following sections describe these qualifiers.

9.5.4.1. /BACKUP Qualifier

The /BACKUP qualifier selects files for decryption according to the date of their most recent backup. This qualifier is meaningful only when used with either the /BEFORE or the /SINCE qualifier. The /BACKUP qualifier has the format:

/BACKUP /BEFORE[=time]
/BACKUP /SINCE[=time]

where

time is an OpenVMS time.

If you do not specify a time, TODAY is used. TODAY is the current day, month, and year at 00:00:00.

The following command selects for decryption all files in the current directory matching the wildcard file specification of *.COM that had backup copies made before 00:00:00 15-APR-2009.

$ DECRYPT /BACKUP /BEFORE=15-APR-2009 *.COM FRANCISSCOTT

Do not use the /BACKUP qualifier with either the /EXPIRED or the /MODIFIED qualifier.

9.5.4.2. /BEFORE Qualifier

The /BEFORE qualifier selects files for decryption that have a creation date before the time specified with the qualifier. The /BEFORE qualifier has the format:

/BEFORE[=time]

where

time is an OpenVMS time.

If you do not specify a time, TODAY is used. TODAY is the current day, month, and year at 00:00:00.

The following command selects for decryption all files in the current directory matching the wildcard file specification of *.COM that were created before 00:00:00 15-APR-2009.

$ DECRYPT /BEFORE=15-APR-2009 *.COM FRANCISSCOTT

9.5.4.3. /BY_OWNER Qualifier

Use the /BY_OWNER qualifier to select files for decryption that have a particular owner User Identification Code (UIC). If no UIC is specified with the qualifier, the UIC of the current process is used. The /BY_OWNER qualifier has the format:

BY_OWNER=uic

where

uic is the UIC of the owner of the file.

9.5.4.4. /CONFIRM Qualifier

By default, all input files specified on the command line are processed without confirming that each file is selected for decryption. Use the /CONFIRM qualifier if you want a prompt with the name of each file selected for decryption. Your response controls whether or not a particular file is decrypted.

You can choose any of the following responses:

ResponseMeaning
YESDecrypt the file.
NO or RETURNDo not decrypt the file. This is the default.
QUIT or Ctrl/ZDo not decrypt the file or any subsequent files.
ALLDecrypt the file and all subsequent files.

The following command selects all files in the current directory matching the wildcard file specification of *.COM for decryption. Because the /CONFIRM qualifier is specified, the user is prompted on a file-by-file basis to confirm that each file is to be decrypted. Because the prompt is answered in the affirmative for the file MOVE.COM;3, the output file MOVE.COM;4 is created.

$ DECRYPT /CONFIRM *.COM FRANCISSCOTT
Decrypt DISK2:[FLYNN]MOVE.COM;3 ? [N] YES

9.5.4.5. /EXCLUDE Qualifier

Use the /EXCLUDE qualifier to exclude one or more files from a decryption operation. If a file matches the file specification provided with the qualifier, the file is not decrypted. The /EXCLUDE qualifier has the format:

/EXCLUDE=((file-spec)[,...])

where

file-spec is the file specification of the file to remain encrypted.

When specifying only one file, you can omit the parentheses. Wildcard characters are allowed in the file specification. With the /EXCLUDE qualifier, there is no default for the file specification.

Since directory files are never encrypted, you need not specify them with the /EXCLUDE qualifier. However, if you do specify /EXCLUDE=*.DIR, you will not get the warning message %ENCRYPT-W-FILNODIR, file encryption of directories is not supported, filename.dir.

The following command selects for decryption all files in the current directory that match the wildcard file specification of *.COM, except LOGIN.COM, which is specified with /EXCLUDE.

$ DECRYPT /EXCLUDE=LOGIN.COM *.COM FRANCISSCOTT

9.5.4.6. /EXPIRED Qualifier

The /EXPIRED qualifier selects files for decryption according to the dates on which they expire. (The expiration date is set with the SET FILE/EXPIRATION_DATE command.) This qualifier is meaningful only when used with either the /BEFORE or the /SINCE qualifier. The /EXPIRED qualifier has the format:

/EXPIRED /BEFORE[=time]
/EXPIRED /SINCE[=time]

where

time is an OpenVMS time.

If you do not specify a time, TODAY is used. TODAY is the current day, month, and year at 00:00:00.

The following command selects for decryption all files in the current directory matching the wildcard file specification of *.COM that expire after 00:00:00 15-APR-2009.

$ DECRYPT /EXPIRED /SINCE=15-APR-2009 *.COM FRANCISSCOTT

Do not use the /EXPIRED qualifier with either the /BACKUP or the /MODIFIED qualifier.

9.5.4.7. /MODIFIED Qualifier

The /MODIFIED qualifier selects files for decryption according to the dates on which they were last modified. This qualifier is meaningful only when used with either the /BEFORE or the /SINCE qualifier. The /MODIFIED qualifier has the format:

/MODIFIED /BEFORE[=time]
/MODIFIED /SINCE[=time]

where

time is an OpenVMS time.

If you do not specify a time, TODAY is used. TODAY is the current day, month, and year at 00:00:00.

The following command selects for decryption all files in the current directory matching the wildcard file specification of *.COM that were modified after 00:00:00 15-APR-2009.

$ DECRYPT /MODIFIED /SINCE=15-APR-2009 *.COM FRANCISSCOTT

Do not use the /MODIFIED qualifier with either the /BACKUP or the /EXPIRE qualifier.

9.5.4.8. /SINCE Qualifier

The /SINCE qualifier selects files for decryption that have a creation date after the time specified with the qualifier. The /SINCE qualifier has the format:

/SINCE[=(time)]

where

time is an OpenVMS time.

If you do not specify a time, TODAY is used. TODAY is the current day, month, and year at 00:00:00.

The following command selects for decryption all files in the current directory matching the wildcard file specification of *.COM that were created after 00:00:00 15-APR-2009.

$ DECRYPT /SINCE=15-APR-2009 *.COM FRANCISSCOTT

9.5.5. Deleting Decrypted Files

By default, the input file is retained after a file is decrypted and written to the resulting output file. To save space, after you have decrypted a file, you may want to remove the encrypted file from your disk.

You can use the DCL DELETE command with the /ERASE qualifier to remove the contents of the file from the disk, or you can use the /DELETE and /ERASE qualifiers with the DECRYPT command.

9.5.5.1. /DELETE Qualifier

The /DELETE qualifier deletes the input file after the decryption operation completes and the output file is written and closed. If you have multiple versions of the input file, they are not all deleted. /DELETE acts on only the version of the input file that you encrypted.

The following command specifies that the SAVEDMAIL.MAI file be decrypted using the TWENTYFIVECENTS encryption key. Because the /DELETE qualifier is specified, the input file is deleted after the output file is written.

$ DECRYPT /DELETE SAVEDMAIL.MAI TWENTYFIVECENTS

9.5.5.2. /ERASE Qualifier

To prevent disk scavenging, use the /ERASE qualifier with the /DELETE qualifier. For example, the following command decrypts the SAVEDMAIL.MAI file using the TWENTYFIVECENTS encryption key, erases the input file with the data security pattern, and deletes the file.

$ DECRYPT /DELETE /ERASE SAVEDMAIL.MAI TWENTYFIVECENTS

With the following command, the SAVEDMAIL.MAI file is decrypted using the TWENTYFIVECENTS encryption key, but the input file is not erased with the data security pattern before being deleted.

With the following command, the SAVEDMAIL.MAI file is decrypted using the TWENTYFIVECENTS encryption key, but the input file is not erased with the data security pattern before being deleted.

$ DECRYPT /DELETE /NOERASE SAVEDMAIL.MAI TWENTYFIVECENTS

9.5.6. Algorithm Qualifiers

The algorithm qualifier you use to encrypt determines the correct decryption procedure:

  • If you use the /DATA_ALGORITHM qualifier to encrypt, do not specify this algorithm when you decrypt.

  • If you use the /KEY_ALGORITHM qualifier to encrypt, specify this algorithm when you decrypt.

The /KEY_ALGORITHM qualifier has the format:

/KEY_ALGORITHM=(algorithm)

where

algorithm is one of the following values:

  • DESCBC (the default)

  • DESECB

  • DESCFB

For example, if SAVEDMAIL.MAI is encrypted with /KEY_ALGORITHM=DESCFB, decrypt the file with the same /KEY_ALGORITHM=DESCFB qualifier, as follows:

$ ENCRYPT /KEY_ALGORITHM=DESCFB SAVEDMAIL.MAI TWENTYFIVECENTS
$ DECRYPT /KEY_ALGORITHM=DESCFB SAVEDMAIL.MAI TWENTYFIVECENTS

9.6. Encrypting save sets

The OpenVMS BACKUP utility provides protection against file or volume corruption by creating functionally equivalent backup copies. Files created by BACKUP are called save sets and are written in BACKUP format so that only BACKUP can interpret the data in a save set. When you create save sets, you can also encrypt them by using the BACKUP /ENCRYPT command.

Note

Standalone BACKUP, which is a version of the BACKUP utility that runs without the support of the OpenVMS operating system, does not support the /ENCRYPT qualifier.

BACKUP /ENCRYPT requires a key. All the files in the save set are encrypted under the same key. When you use the /ENCRYPT qualifier to specify a write operation for an encrypted save set, the BACKUP utility creates a key by generating a 16-byte random number from the time of day and other transient data. To make this random number even more random, BACKUP encrypts this 16-byte value once using itself as a key with the DESCBC algorithm. The first eight bytes of the result are used as the encrypting key for the save set, and the second eight bytes are used as the initialization vector for the context area.

One benefit of this procedure is that two save sets created with the same command from the same set of files are not identical in their encrypted form.

You can override the system-generated encrypting key and initialization vector by issuing either of the following commands:

  • ENCRYPT /CREATE_KEY

  • BACKUP /ENCRYPT=(VALUE=key-value)

For greater security, specify the /ENCRYPT qualifier with no parameters. The software prompts you for a key value. When you enter it, the software does not echo what you type and, for verification, prompts you to retype the value.

If you define a key with the ENCRYPT /CREATE_KEY command, specify that key name on the BACKUP command line with the /ENCRYPT=(NAME=(key-name)) qualifier.

By default, BACKUP encrypts save set data using the DESCBC algorithm. The key and algorithm you specify to override the defaults are used to encrypt only the data key and the initialization vector.

BACKUP places the result of the encryption operation in the save set as a BACKUP attribute subrecord of the BACKUP summary record. At the time of a save set restore or listing operation, BACKUP uses the system-generated key or the key you supplied to decrypt the data key and the initialization vector value.

The BACKUP command qualifier /SAVE_SET is both an input save set qualifier and an output save set qualifier, as follows:

  • When you specify the /SAVE_SET and /ENCYRPT qualifiers with an output save set specification, BACKUP writes file data (including file names and attributes) in an encrypted form into the save set.

  • When you specify /SAVE_SET with an input save set specification, BACKUP uses the decryption key specified to access the file name, attributes, and data from the save set records. The ENCRYPT option decrypts the data files after BACKUP reads the data files from the save set medium and processes them according to the remaining qualifiers of the BACKUP command.

The following example creates an encrypted BACKUP file of the default directory, as follows:

  1. ENCRYPT /CREATE_KEY defines a key, SANFRANCISCO, with this value: A city set on a hill cannot be hid.

  2. BACKUP /ENCRYPT saves all the files in the default directory in a save set named 28JULSAVE.BCK and encrypts the save set.

    On device MKA600:, the data used to encrypt the file names, attributes, and all the other file data are encrypted with the default encryption algorithm DESCBC. The process uses the key defined as SANFRANCISCO.

    $ ENCRYPT /CREATE_KEY SANFRANCISCO "A city set on a hill cannot be hid"
    $ BACKUP /ENCRYPT=(NAME=SANFRANCISCO) * MKA600:28JULSAVE.BCK /SAVE_SET 

The following example creates a save set of the latest version of all the files on a disk. The save set is encrypted using the DESCFB algorithm and the key value Make peace.

$ BACKUP /ENCRYPT=(VALUE="Make peace",ALGORITHM=DESCFB) *.* 28JULSAVE
/SAVE_SET 

9.6.1. Restoring Files

When you encrypt a save set, BACKUP does not store the information within the save set. Consequently, to decrypt an encrypted save set, specify /ENCRYPT with the RESTORE command so that BACKUP searches for the data encryption control record.

If you restore an unencrypted save set and mistakenly specify /ENCRYPT, BACKUP ignores the incorrect qualifier. If you try to restore an encrypted saveset without the /ENCYRPT qualifier or with a key name, you get the error message:

%BACKUP-F-ENCSAVSET, save set is encrypted, /ENCRYPT must be specified

The following commands restore file SALARY.DAT from a save set created with a BACKUP /ENCRYPT command:

$ ENCRYPT /CREATE_KEY CASTERBRIDGE "And all her shining keys"
$ BACKUP /ENCRYPT=(NAME=CASTERBRIDGE)
_$ From: MKA600:28JULSAVE.BCK /SELECT=SALARY.DAT
_$ To: SALARY28J.DAT

BACKUP tries to decrypt an encrypted save set by:

  1. Decrypting the encryption data that was saved in an attribute subrecord.

  2. Comparing a 32-bit checksum of the decrypted data key with the stored value.

  3. If there is a match, BACKUP assumes the data key is valid and restores the save set.

  4. If BACKUP finds a mismatch, which is likely if the data key or algorithm you specified in the BACKUP command is incorrect, the utility displays:

    %BACKUP-F-ENCKEYMAT, the supplied decryption key does not yield a readable save set

9.6.2. Encrypting Distribution Files

BACKUP /ENCRYPT can create a distribution disc that is useful only to a customer who has the key used to encrypt the save sets in the distribution kit.

In the following example, three keys are defined with ENCRYPT /CREATE_KEY commands. With each of these keys, a software distribution disc is created with each product encrypted into its respective save set under a unique key.

$ ENCRYPT /CREATE_KEY SDXKEY "SDX V9.0 kit 99804034671838302"
$ BACKUP /ENCRYPT=(NAME=SDXKEY) /REWIND -
_From: MASTER:[SDXKIT]*.* MKA600:SDXKIT /SAVE_SET

$ ENCRYPT /CREATE_KEY RQPKEY "RQP V4.5 kit FWTEBCJDITROEMMKAZXRYTC"
$ BACKUP /ENCRYPT=(NAME=RQPKEY) -
_From: MASTER:[RQPKIT]*.* MKA600:RQPKIT /SAVE_SET

$ ENCRYPT /CREATE_KEY WOLKEY "WOL V2.0 kit 28374UEJDTLHGD84JF849SK95KD0"
$ BACKUP /ENCRYPT=(NAME=WOLKEY) -
_From: MASTER:[WOLKIT]*.* MKA600:WOLKIT /SAVE_SET 

The resulting save sets can be restored on a customer's system only if the customer has received the appropriate key by licensing arrangement.

For example, the following commands restore save set WOLKIT:

$ ENCRYPT /CREATE_KEY WOLKEY "WOL V2.0 kit 28374UEJDTLHGD84JF849SK95KD0"
$ BACKUP /ENCRYPT=(NAME=WOLKEY) MKA600:WOLKIT /SAVE_SET SYSTEM:[RQPKIT]*.* 

In the following example, the save set SDXKIT is restored without typing the key name and key value on the command line. Instead, the BACKUP /ENCRYPT command prompts for this information, which is not echoed on your screen.

$ BACKUP /ENCRYPT /REWIND MKA600:SDXKIT /SAVE_SET SYSTEM:[SDXKIT]*.*
Enter Key Value: (input not echoed)
Verify: (input not echoed) 

Chapter 10. Security Auditing

This chapter describes how to use and manage the OpenVMS auditing system. It explains how you can monitor security-relevant activity on your system by recording events as they occur on the system and subsequently analyzing this audit log.

10.1. Overview of the Auditing Process

Auditing is the recording of security-relevant activity as it occurs on the system and the subsequent analysis of this audit log. With auditing, you can monitor users' activity on the system and, if necessary, reconstruct events leading up to attempts to compromise the security of your system. Thus, it is not as much a method of protecting the system and its data as a method of analyzing and recording system use.

Anything that has to do with a user's access to the system or to a protected object within the system is considered a security-relevant activity. Such activities are called events. Typical events include the following:

  • Logins, logouts, or login failures

  • Changes to the authorization database

  • Access to a protected object, such as a file, device, or global section

  • Changes in privileges or the security attributes of protected objects

The operating system can record both successful and unsuccessful events. Sometimes the unsuccessful can be more revealing. For example, it is less important to record that a programmer displayed a file to which he had access than that the same programmer tried to but was prevented from displaying a protected file.

The event message itself can be written to two places: an audit log file or an operator terminal that is enabled to receive security class messages. As Example 10.1 shows, a message contains the following data:

  1. Date and time of the message

  2. Type of event

  3. Date and time the event occurred

  4. The process identification (PID) of the user who caused the event

Additional information in auditing messages is specific to the type of event. See Example 10.1 for examples of different messages.

Example 10.1. Sample Alarm Message
%%%%%%%%%%%  OPCOM  25-JUL-2008 16:07:09.20  %%%%%%%%%%%
Message from user AUDIT$SERVER on GILMORE
Security alarm (SECURITY) on GILMORE, system id: 20300
Auditable event:          Process suspended ($SUSPND)
Event time:               25-JUL-2008 16:07:08.77
PID:                      30C00119
Process name:             Hobbit
Username:                 HUBERT
Process owner:            [LEGAL,HUBERT]
Terminal name:            RTA1:
Image name:               $99$DUA0:[SYS0.SYSCOMMON.][SYSEXE]SET.EXE
Status:                   %SYSTEM-S-NORMAL, normal successful completion
Target PID:               30C00126
Target process name:      SMISERVER
Target username:          SYSTEM
Target process owner:     [SYSTEM]

10.2. Reporting Security-Relevant Events

Beyond a certain set of default reporting (see Table 10.1), the kind of security event information you receive depends on the kind of information you select from a long list of possible events. This section explains how to enable the reporting of security event information. Specifically, it discusses the following topics:

  • Ways to generate event messages

  • Types of events the system can report

  • Sources of event information

10.2.1. Ways to Generate Audit Information

Whenever you install or upgrade your system, the OpenVMS operating system automatically audits a limited number of events. These event categories, which are shown in Table 10.1, represent major changes in the security of your system. Depending on your site's requirements, you may want to enable other forms of reporting.

You can have the operating system report on security-related activity in three different ways:

  • By enabling a category of events for auditing. For example, all login failures or all changes to system parameters can be reported.

  • By attaching an access control entry (ACE) to a protected object. For example, any time a user modifies a particular file, a message can be generated.

  • By modifying a user's authorization record so the system audits all operations performed from the account.

10.2.1.1. Auditing Categories of Activity

Security-relevant events are divided into a number of categories called event classes. The operating system audits several event classes by default (see Table 10.1). If the security requirements at your site justify additional auditing, you enable security auditing for additional event classes by using the DCL command SET AUDIT.

To enable auditing for different event classes, use the following command format:

SET AUDIT /ENABLE=event-class[,...] {/ALARM | /AUDIT}

The command requires two qualifiers to enable events:

  • The /ENABLE qualifier defines the event classes you want audited. See Table 10.3 for a list of event classes.

  • The /AUDIT qualifier or the /ALARM qualifier defines the destination for the event message.

    The /AUDIT qualifier directs the message to the audit log file, whereas the /ALARM qualifier directs the message to an operator terminal that has been enabled to receive security event messages. Critical events should be reported as both audits and alarms; less critical events can be written to a log file for later examination. The default event classes listed in Table 10.1 are audited as both alarms and audits.

The operating system begins auditing the new events on all nodes of the cluster as soon as you enable them. It continues auditing until you explicitly disable the classes with the /DISABLE qualifier. The current auditing configuration is recorded in SYS$MANAGER:VMS$AUDIT_SERVER.DAT and so it is preserved across system boots.

For more information about the SET AUDIT command, see the VSI OpenVMS DCL Dictionary.

Table 10.1. Event Classes Audited by Default
ClassDescription
ACLAccess to any object holding a security-auditing ACE.
AuditAll uses of the SET AUDIT command. This category cannot be disabled.
Authorization

All changes to the authorization database:

  • System user authorization file (SYSUAF.DAT)

  • Network proxy authorization file (NETPROXY.DAT or NET$PROXY.DAT)

  • Rights database (RIGHTSLIST.DAT)

Break-inAll intrusion attempts: batch, detached, dialup, local, network, remote.
LogfailureAll login failures: batch, dialup, local, remote, network, subprocess, detached, server.

To see the event classes your site currently audits, enter the DCL command SHOW AUDIT. Example 10.3 displays the audit settings for a site with moderate security requirements.

10.2.1.2. Example of Enabling Event Classes

Although you can enable auditing for every possible class of security activity (/ENABLE=ALL), such an approach can result in an excessive number of auditing messages and generates too much information to analyze in a meaningful way. Therefore, VSI suggests that you evaluate your needs, as described in Section 10.3.1, and selectively audit system activity.

You can enable auditing of event classes with different levels of granularity. You can use the following methods:

  • Enable a class

    To enable auditing for all login failures, for example, you enable the logfailure class by entering the following command:

    $SET AUDIT/AUDIT/ENABLE=LOGFAILURE=ALL

    As a result of this command, the audit server reports all login failures in the security audit log file.

  • Enable a subset of a class

    With certain events, you may want to be more selective in the kinds of reporting you enable. For example, it makes more sense to enable network and remote login events rather than to enable all login events.

    To enable auditing of only the network and remote logins, enter the following command:

    $SET AUDIT/AUDIT/ENABLE=LOGIN=(NETWORK,REMOTE)
  • Enable successful, unsuccessful, or privileged events

    Event messages that report on normal system use can easily be eliminated if you enable only unsuccessful event reports or reports for activity performed through a certain privilege.

    When auditing access events to protected objects, in particular, you need to define your information requirements more finely than you would with event classes like logins or use of the Install utility. Files and certain other protected objects are accessed so often that full enabling of the related access event class can result in an overwhelming number of event messages---so many that they can possibly mask the unusual events that do require investigation. For this reason, it is recommended that you enable access auditing only for unusual conditions, such as unsuccessful or privileged access events.

    To enable auditing of unsuccessful file access events, enter the following command:

    $SET AUDIT/AUDIT/ENABLE=ACCESS=FAILURE/CLASS=FILE

    Notice that the previous command enables auditing for all failed file accesses, not just failed read or write access attempts. This is recommended because access operations can be quite involved: what appears to be a simple write operation can involve several types of access. (For example, before writing to the file, the operation requires access to the volume and read access to the directory as well as access to the file within it.)

    Example 10.2 displays an event message from a file access failure. User Robinson tried to delete the file FOO.BAR, but an ACE on the file prevented it. Apparently, Robinson holds the identifier MINDCRIME, and an Identifier ACE on FOO.BAR denies access to those holding such an identifier. Furthermore, because the system owns the file, Robinson cannot gain delete access to the file through the protection code either.

Example 10.2. Audit Generated by an Object Access Event
Message from user AUDIT$SERVER on BILBO
Security alarm (SECURITY) and security audit (SECURITY) on BILBO,
                       system id: 19662
Auditable event:       Object deletion
Event information:     file deletion request (IO$_DELETE)
Event time:            24-APR-2008 13:17:24.59
PID:                   47400085
Process name:          Hobbit
Username:              ROBINSON
Process owner:         [ACCOUNTING,ROBINSON]
Terminal name:         OPA0:
Image name:            DSA2264:[SYS51.SYSCOMMON.][SYSEXE]DELETE.EXE
Object class name:     FILE
Object owner:          [SYSTEM]
Object protection:     SYSTEM:RWED, OWNER:RWED, GROUP:RE, WORLD:RE
File name:             _DSA2200:[ROBINSON]FOO.BAR;1
File ID:               (17481,6299,1)
Access requested:      DELETE
Matching ACE:          (IDENTIFIER=MINDCRIME,ACCESS=NONE)
Sequence key:          00008A41
Status:                %SYSTEM-F-NOPRIV, no privilege for attempted operation

10.2.2. Attaching a Security-Auditing ACE

As Section 10.2.1.1 describes, auditing access to protected objects requires careful thought because this type of event occurs so frequently. Too many event messages can overwhelm you and possibly mask the unusual events that do require investigation.

A more selective method of auditing protected objects is to include an auditing ACE in an object's access control list (ACL) and enable the ACL event class. With this approach, only access to objects with security-auditing ACEs results in an event message, not all objects of a class.

You can use two different types of auditing ACEs, depending on where you want the event reported. Alarm ACEs direct event messages to the operator terminal; whereas Audit ACEs direct event messages to the audit log file. Table 10.2 summarizes the auditing ACEs, and the VSI OpenVMS System Management Utilities Reference Manual provides a full description of them. See Table 11.1 for a list of system files benefiting from auditing ACEs.

Table 10.2. Access Control Entries (ACEs) for Security Auditing
ACE TypeDescription
Alarm ACE

Writes an event message to the operator terminal whenever the object is accessed in the specified manner. It has the following syntax:

(ALARM=SECURITY[,OPTIONS=options],ACCESS=access-type[+access-type...])

Audit ACE

Writes an event message to the security audit log file whenever the object is accessed in the specified manner. It has the following syntax:

(AUDIT=SECURITY [,OPTIONS=options],ACCESS=access-type[+access-type...])

You attach an ACE to sensitive objects by using the DCL command SET SECURITY/ACL or the access control list editor (ACL editor). Always include the SUCCESS or FAILURE keyword (or both) in the ACCESS statement of an auditing ACE.

It is a good idea to define auditing ACEs for critical system files that are not automatically audited, such as the automatic login file SYSALF.DAT, the operator log file OPERATOR.LOG, or the system accounting file ACCOUNTING.DAT. Do not monitor all access conditions, however, because such an approach can generate a large volume of messages, many of which are not useful. For example, tracking successful write operations to OPERATOR.LOG probably will not produce interesting information, but tracking unsuccessful attempts probably will.

You can add auditing ACEs to any protected object, although files are the most common objects to audit. You may want to add an auditing ACE to either a print queue that is handling sensitive documents or to a terminal to catch attempted password grabbers (see Section 3.8).

10.2.2.1. Example of Adding an Auditing ACE

To establish an Alarm ACE for the file ACCOUNTING.DAT, enter the following command:

$ SET SECURITY/ACL=(ALARM=SECURITY,ACCESS=DELETE+CONTROL+SUCCESS+FAILURE)-_$ SYS$MANAGER:ACCOUNTING.DAT

The ACL event class is enabled by default, but if it has been disabled at a site, you must enter the following command to reenable the use of auditing ACEs:

$SET AUDIT/ALARM/AUDIT/ENABLE=ACL

10.2.3. Modifying a User Authorization Record

Sometimes you may see users acting in a suspicious way. Perhaps they are logging in from a number of terminals or logging in at unusual times of the day or the week. You can monitor users' actions by modifying the auditing attribute in their user authorization records. Run the AUTHORIZE utility and set the Audit flag.

Note that setting the AUDIT flag generates an extremely large number of audit messages. The following command sequence modifies the account of user Robin:

$RUN SYS$SYSTEM:AUTHORIZE
UAF>MODIFY ROBIN/FLAGS=AUDIT
%UAF-I-MDFYMSG, user record(s) updated

With the Audit flag set, the operating system audits the user's process. The audit log file contains a report of any action the user performs that the operating system is capable of auditing (see Section 10.2.4). You can use the Audit Analysis utility to review the user's actions. For example, to get a report on the activities of user Robin, enter the following command:

$ANALYZE/AUDIT/SELECT=(FLAGS=MANDATORY,USERNAME=ROBIN) -
_$SECURITY.AUDIT$JOURNAL

See Section 10.5 for a full description of the Audit Analysis utility.

10.2.4. Kinds of System Activity the Operating System Can Report

With the DCL command SET AUDIT, you can enable auditing for one or more of the event classes shown in Table 10.3. Many of the events classes have keywords permitting you to define a subset of the event class (VAX specific).

Table 10.3. Kinds of Security Events the System Can Report
Event ClassDescription
AccessAccess requests to all objects in a class. You can audit selected types of access, both privileged and nonprivileged, to all protected objects of a particular class.
ACLEvents requested by a security Audit or Alarm ACE in the ACL of an object.
AuthorizationModification of any portion of SYSUAF.DAT, NETPROXY.DAT, NET$PROXY.DAT, or RIGHTSLIST.DAT.
BreakinIntrusion attempts.
ConnectionLogical link connections or terminations through SYSMAN, DECnet Phase IV (VAX specific), VSI DECwindows Motif for OpenVMS, or an interprocess communication (IPC) call.
CreateCreation of a protected object.
DeaccessDeaccess from a protected object.
DeleteDeletion of a protected object.
IdentifierUse of identifiers as privileges.
InstallModifications made to the known file list through the Install utility.
LogfailureUnsuccessful login attempts.
LoginSuccessful login attempts.
LogoutLogouts.
MountVolume mounts and dismounts.
NCPModification to the network configuration database, using the network control program (NCP).
PrivilegeSuccessful or unsuccessful use of privilege.
ProcessUse of one or more of the process control system services.
SYSGENModification of a system parameter with the System Generation utility (SYSGEN) or AUTOGEN.
TimeModification of system time.

10.2.4.1. Suppression of Certain Privilege Audits

Although a site may enable the privilege event class, the operating system does not report every event in this class. It suppresses the following types of audits:

  • Successful use of privileges with which an image is installed

    For example, the image SHOW.EXE is installed with WORLD privilege. When unprivileged users enter the SHOW SYSTEM command, SHOW.EXE uses WORLD privilege to perform wildcard $GETJPI system service calls. This use of WORLD privilege is not audited. However, if the same unprivileged users attempt to use the SHOW PROCESS command to display process