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

Input	Algorithm	Output
User-supplied data key	Key encryption	Encrypted key
Data (plaintext) and the encrypted data key	Data encryption	Encrypted 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.

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

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:

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.

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

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.

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.

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.

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

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.

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

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.

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.

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

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.

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.

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.

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.

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.

     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.

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.

WILLOW - A member of the Forest Cluster                      
Unlawful Access is Prohibited
Username:  RWOODS
Password:
  You have the following disconnected process:               
Terminal   Process name    Image name
VTA52:     RWOODS          (none)
Connect to above listed process [YES]:
NO
           Welcome to OpenVMS on node WILLOW                 
    Last interactive login on Wednesday,  3-DEC-2008 10:20   
    Last non-interactive login on Monday, 3-DEC-2008 17:39   
         2 failures since last successful login              
           You have 1 new mail message.                      
$

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.

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.

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

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.

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

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.

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.

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.

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

$ SET PASSWORD
Old password:
Return                     
reankuna      rean-ku-na   
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 
New password:
Return   
Verification:
Return   
$ 

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.

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.

  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.

WARNING – Your password expires on Thursday 18-DEC-2008 15:00

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

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.

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.

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.

NODE"username password"::disk:[directory]file.type

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

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 diagram illustrates these conditions:

$ COPY WALNUT"KMAHOGANY A25D3255"::BIONEWS.MEM  BIONEWS.MEM

$ 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

$ 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

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

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.

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.

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

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.

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

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.

$ LOGOUT
RDOGWOOD     logged out at 14-AUG-2008 19:39:01.43

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.

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.

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.

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.

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 kernel threads block (KTB) points to the persona block for the currently active thread.

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.

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.

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.

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.

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.

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.

$ 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]                
Base priority:      4
Default file spec:  WORK1:[GREG.FISCAL_91]
Devices allocated:  ACCOUNTS$TWA2:
Process Quotas:
  .
  .
  .
Process rights:
 INTERACTIVE                                 
 LOCAL                                       
 SALES                                       
 MINDCRIME                         resource  

System rights:
 SYS$NODE_ACCOUNTS                         

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

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.

$ 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

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

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.

[user category: access allowed (,user category: access allowed,...)]

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

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.

$ SET SECURITY/PROTECTION=(W:RW) 93_FORECAST.TXT

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

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.

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

$  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)

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

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

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.

SET SECURITY/ACL=(IDENTIFIER=identifier,ACCESS=access-type)

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

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.

$ SET SECURITY/ACL=(IDENTIFIER=[PAT],ACCESS=READ+WRITE+EXECUTE)-
_$ DISK1:[ROBERTS]JULY-SALES.TXT

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

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.

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

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.

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

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.

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

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

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.

$ SET SECURITY/ACL=(IDENTIFIER=PERSONNEL,OPTIONS=DEFAULT,-
_$ ACCESS=READ+WRITE)  [000000]MALCOLM.DIR

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

$ SET SECURITY/ACL=(IDENTIFIER=PERSONNEL,ACCESS=READ+WRITE)-
_$ [MALCOLM]*.*;*

$ SET SECURITY/ACL=-
_$ ((IDENTIFIER=PERSONNEL,ACCESS=READ+WRITE),-
_$ (IDENTIFIER=PERSONNEL,OPTIONS=DEFAULT,ACCESS=READ+WRITE))-
_$ [000000]MALCOLM.DIR

$ 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)

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.

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.

$ SET SECURITY/CLASS=QUEUE/ACL=(IDENTIFIER=WRITERS,-
_$ ACCESS=READ+WRITE)  LN03$PRINT

$  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)

$ SET SECURITY/CLASS=QUEUE/ACL=(IDENTIFIER=TRADERS,ACCESS=WRITE)-
_$ /AFTER=(IDENTIFIER=WRITERS,ACCESS=READ+WRITE) LN03$PRINT

$  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)

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

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

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.

$ SET SECURITY/LIKE=NAME=ACL_TEMPLATE.TXT-
_$ /COPY_ATTRIBUTE=ACL/CLASS=LOGICAL_NAME_TABLE LNM$GROUP

$ 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

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

[user category: list of access allowed (, user category: list of access allowed,...)]

user category

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

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.

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

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

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

$ SET SECURITY/PROTECTION=(S,O,G,W)/CLASS=DEVICE TTA8:

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

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

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.

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.

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

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.

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.

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.

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

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.

The only valid name for a capability object is VECTOR.

The capability object's security profile needs to be reset each time the system starts up.

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.

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.

Creation of a permanent common event flag cluster requires the PRMCEB privilege. This privilege also grants delete access for permanent clusters.

A common event flag cluster and its security profile need to be reset each time a system starts up.

See the VSI OpenVMS System Manager's Manual and the VSI OpenVMS User's Manual for a full description of device names.

Devices can be shared and thus have concurrent users or be unshared and have a single user.

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.

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.

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

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

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.

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.

INITIALIZE/ERASE device-name[:]  volume-label

SET VOLUME/ERASE_ON_DELETE device-spec[:]

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.

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

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.

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

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

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

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

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

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.

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.

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

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.

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

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

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

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.

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.

The security profile for a volume object is saved in the master file directory (MFD) of the disk as [000000]SECURITY.SYS.

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.

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

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

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.

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.

/EXPIRATION=30-DEC-2008

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.

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

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

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

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.

$ SET DEFAULT SYS$SYSTEM
$ RUN AUTHORIZE
UAF> ADD RDOGWOOD /PASSWORD=TRALAYAM/UIC=[231,010] -  
_UAF> /DEVICE=BOTANYDEV/DIRECTORY=[RDOGWOOD] -
_UAF> /OWNER="Robert Dogwood"/ACCOUNT=BOTNYDPT -
_UAF> /FLAGS=(GENPWD)/PWDMINIMUM=6 -                  
_UAF> /EXPIRATION=15-JUNE-2003/PWDLIFETIME=90-        
_UAF> /PRIMEDAYS=(MON,TUES,WED,THURS,FRI,SAT,NOSUN) - 
_UAF> /NOACCESS=(PRIMARY,23-6,SECONDARY)/NODIALUP     
identifier for value:[000231,000010] added to RIGHTSLIST.DAT
UAF>

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