OpenVMS System Manager's Manual

To use the automatic password generator while using the Authorize utility 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.

Using the System Dictionary and the Password History List

The OpenVMS operating system automatically compares new passwords with a system dictionary to ensure that a password is not a native language word. It also maintains a password history list of a user's last 60 passwords. The operating system compares each new password with entries in the password history list to ensure that an old password is not reused.

The system dictionary is located in SYS$LIBRARY. You can enable or disable the dictionary search by specifying the DISPWDDIC or NODISPWDDIC option with the /FLAGS qualifier in AUTHORIZE. The password history list is located in SYS$SYSTEM. To enable or disable the history search, specify the DISPWDHIS or NODISPWDHIS option to the /FLAGS qualifier.

Adding to the System Password Dictionary

You can modify the system password dictionary to include words of significance to your site. The following procedure allows you to add words to the system dictionary. The procedure also allows you to retain a file of the passwords that you consider unacceptable.

Create a file containing passwords you want 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]
```

Enable SYSPRV and merge your local additions:

$ SET PROCESS/PRIVILEGE=SYSPRV
$ CONVERT/MERGE/PAD LOCAL_PASSWORD_DICTIONARY.DATA -
_$ SYS$LIBRARY:VMS$PASSWORD_DICTIONARY.DATA

Defining Preexpired Passwords

When you add a new user to the UAF, you might want to define that user's password as having expired previously using the AUTHORIZE qualifier /PWDEXPIRED. This forces the user to change the initial password when first logging in.

Preexpired passwords are conspicuous in the UAF record listing. The entry for the date of the last password change carries the following notation:

(pre-expired)

By default, the OpenVMS operating system forces new users to change their passwords the first time they log in. Encourage your site to use a training program for its users that includes information about changing passwords.

11.2.2 System Passwords

System passwords 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 at computer laboratories at universities
Terminals the security manager wants to reserve for security operations

Implementing system passwords is a two-stage operation involving the DCL commands SET TERMINAL and SET PASSWORD. First, you must decide which terminals require system passwords. Then, for each terminal, you enter the DCL command SET TERMINAL/SYSPASSWORD/PERMANENT. To enable system passwords for all terminals, set the appropriate bit in the system parameter TTY$DEFCHAR2.

11.2.3 Primary and Secondary Passwords

The use of dual passwords is cumbersome and mainly needed at sites with high-level security concerns. The effectiveness of a secondary passwords depends entirely on the trustworthiness of the supervisor who supplies it. A supervisor can easily give out the password or worse yet, change it to a null string.

The main advantage of a second password is that it prevents accounts from being accessed through DECnet for OpenVMS using simple access control.

Another advantage of a second password is that it can serve as a detection tool when a site has unexplained break-ins after the password has been changed and the 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. See the OpenVMS Guide to System Security for an explanation of how to add secondary passwords.

11.2.4 Enforcing Minimum Password Standards

Security managers can use AUTHORIZE to impose minimum password standards for individual users. Specifically, qualifiers and login flags provided by AUTHORIZE control the minimum password length, how soon passwords expire, and whether the user is forced to change passwords at expiration.

Password Expiration

With the AUTHORIZE qualifier /PWDLIFETIME, you can establish the maximum length of time that can elapse between password changes before the user will be forced to change the password or lose access to the account.

The use of a password lifetime forces the user to change the password regularly. The lifetime can be different for different users. Users who have access to critical files generally should have the shortest password lifetimes.

Forcing Expired Password Changes

By default, users are forced to change expired passwords when logging in. Users whose passwords have expired are prompted for new passwords at login. A password is valid for 90 days unless a site modifies the value with the /PWDLIFETIME qualifier.

Minimum Password Length

With the AUTHORIZE qualifier /PWDMINIMUM, you can direct that all password choices must be a minimum number of characters in length. Users can still specify passwords up to the maximum length of 32 characters.

Requiring the Password Generator

The /FLAGS=GENPWD qualifier in AUTHORIZE allows you to force the 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 manager can be more selective.

11.2.5 Guidelines for Protecting Passwords

Observe the following guidelines to protect passwords:

Make certain the password for the SYSTEM account, which is a standard account on all OpenVMS systems, is secure and is changed regularly.
Disable any accounts that are not used regularly with the AUTHORIZE qualifier /FLAGS=DISUSER (for example, SYSTEST and FIELD).
Do not permit an outside or an in-house service organization to choose 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 flag DISUSER, and enable the account only when it is needed. You can also change the password immediately after each use and notify the service group of the new password.
Set appropriate account expiration dates, especially when you know a user has only short-term requirements for an account.
Delete accounts no longer in use.
If you have an account on a system that stores passwords in plaintext (unencrypted), choose a different password on all of your accounts on other machines. Passwords should not even be shared between machines that encrypt the password. A compromised machine can be used to read plaintext on its way into the machine, thereby gaining access to the other machine.
Do not leave listings of operator logs, accounting logs, or audit logs where they could be read or stolen.
Maintain adequate protection of authorization files. Note that the system user authorization file (SYSUAF.DAT) and network proxy authorization file (NETPROXY.DAT) are owned by the system account ([SYSTEM]). There should be no other users in this group. Accordingly, the categories SYSTEM, OWNER, and GROUP are synonymous. Normally the default UIC-based file protection for these authorization files is adequate.

The following actions are not strictly for password protection, but they 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.
Separate users into distinct user groups.
Protect telephone numbers for dialup lines connected to your system.
Make all accounts that do not require a password captive accounts.
Extend privileges to users carefully.
Ensure that the files containing components of the operating system are adequately protected.

11.2.6 Password History

The password history database maintains a history of previous passwords associated with each user account. By default, the system retains these records for one year. Password history records that are older than the system password history lifetime are allowed as valid password choices. When a user account is deleted, the system removes the associated password history records from the history database.

11.3 Using Intrusion Detection Mechanisms

This section describes how to set up intrusion detection and evasion and how to display the intrusion database.

Controlling the Number of Retries on Dialups

You can control the number of login attempts the user is allowed through a dialup line. If the user makes a typing mistake after obtaining the connection, the user does not automatically lose the connection. This option is useful for authorized users, while still restricting the number of unauthorized attempts.

To implement control of retries, use the following two LGI system parameters: LGI_RETRY_TMO and LGI_RETRY_LIM. If you do not change the values of these system parameters, the default values allow the users three retries with a 20-second interval between each.

Keep in mind that controlling dialup retries is only a part of an overall security program and is not, in itself, sufficient to avoid break-ins. An obstacle like redialing is not going to prove an effective deterrent to a persistent intruder.

Discouraging Break-in Attempts Further

The OpenVMS operating system offers additional methods of discouraging break-in attempts. These methods also use system parameters in the LGI category.

Parameter Description

LGI_BRK_LIM Defines a threshold count for login failures. When the count of login failures exceeds the LGI_BRK_LIM value within a reasonable time interval, the system assumes that a break-in is in progress.

LGI_BRK_TERM Controls the association of terminals and user names for counting failures.

LGI_BRK_TMO Controls the time period in which login failures are detected and recorded.

LGI_HID_TIM Controls the duration of the evasive action.

LGI_BRK_DISUSER Makes the effects of intrusion detection more severe. If you set this parameter to 1, the OpenVMS operating system sets the DISUSER flag in the UAF record for the account where the break-in was attempted. Thus, that user name is disabled until you manually intervene.

Parameter	Description
LGI_BRK_LIM	Defines a threshold count for login failures. When the count of login failures exceeds the LGI_BRK_LIM value within a reasonable time interval, the system assumes that a break-in is in progress.
LGI_BRK_TERM	Controls the association of terminals and user names for counting failures.
LGI_BRK_TMO	Controls the time period in which login failures are detected and recorded.
LGI_HID_TIM	Controls the duration of the evasive action.
LGI_BRK_DISUSER	Makes the effects of intrusion detection more severe. If you set this parameter to 1, the OpenVMS operating system sets the DISUSER flag in the UAF record for the account where the break-in was attempted. Thus, that user name is disabled until you manually intervene.

See the OpenVMS Guide to System Security for a full description of these parameters.

Displaying the Intrusion Database

The Security Server process, which is created as part of 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 intrusion database keeps 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.

Use the DCL command SHOW INTRUSION to display the contents of the intrusion database. Use the DCL command DELETE/INTRUSION_RECORD to remove entries from the intrusion database.

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. The information contained in this database is managed by the Authorize utility.

Example 11-1 shows the expanded expiration time field in the new SHOW INTRUSION output.

Example 11-1 SHOW INTRUSION Output

$ SHOW INTRUSION 
Intrusion       Type       Count        Expiration         Source 
   NETWORK      SUSPECT       1   21-MAY-1996 12:41:01.07  DEC:.ZKO.TIDY::SYSTEM

11.4 Understanding Ways to Protect Objects

The OpenVMS operating system offers two primary protection mechanisms. The first, UIC-based protection, is based on the user identification code (UIC) and is applied to all protected objects.

The second protection mechanism uses access control lists (ACLs), which employ a more refined level of protection than that available with UIC-based protection. ACLs can be used to grant or deny access to individual users or groups of users.

11.4.1 Interpreting a User Identification Code

Your user identification code (UIC) tells what group you belong to and what your unique identification is within that group.

The Authorize utility assigns each user process in the system a unique UIC in the user authorization file (UAF). Each object on the system is also associated with a UIC (typically the UIC of its creator).

A UIC consists of two parts, group and member, specified in the following format:

[group,member]

A UIC can be either numeric or alphanumeric. A numeric UIC consists of a group number in the range 0 through 37776 (octal) and a member number in the range 0 through 177776 (octal). Digital reserves group 1 and groups 300--377.

11.4.2 Understanding Protection Codes

A protection code controls the type of access allowed (or denied) to a particular user or group of users. It 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.

A null access specification means no access, so when you omit an access type for a user category, that category of user is denied that type of access. 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.

When you omit a user category from a protection code, the current access allowed that category of user remains unchanged.

access-list

Access types are object-dependent and are described in the OpenVMS Guide to System Security. 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 (:).

Example

The protection code in the following example allows system users full access to an object, the owner full access except delete, and group and world users no access:

$ SET SECURITY/PROTECTION=(S:RWED,O:RWE,G,W) [JONES]MY_FILE.TXT

How to Change the Default Protection

The operating system provides each process with a default UIC-based protection of (S:RWED,O:RWED,G:RE,W). To change the default protection, enter the SET PROTECTION/DEFAULT command as shown in the following example:

$ SET PROTECTION=(S:RWED,O:RWED,G:RE,W:RE)/DEFAULT

11.5 Creating Access Control Lists

For most interactive user accounts, the default UIC-based protection is adequate. However, in some cases (such as project accounts) you may want to set up an additional level of protection by using access control lists (ACLs). ACL-based protection provides a more refined level of security in cases where different groups or members of overlapping groups share access to an account.

11.5.1 Kinds of Entries in an ACL

An access control list (ACL) is a list of entries, each of which defines some attribute of an object. Each entry is called an access control entry (ACE).

The following security-relevant types of ACEs are available:

ACE Description

Identifier ACE Controls the types of access allowed to specific users based on the user's identification. Each Identifier ACE includes one or more rights identifiers and a list of the types of access the user holding the identifier has permission to exercise. See Section 11.5.2 for a summary of identifiers.
For example, the following ACE grants the user Jones read, write, and execute access to an object:
(IDENTIFIER=[ACCOUNTING,JONES],ACCESS=READ+WRITE+EXECUTE)

Default Protection ACE Allows you to specify a protection code for a directory file that is propagated to all files created within that directory and its subdirectories.
For example, the following ACE assigns a protection code to newly created files in a directory. The code gives users in the system and owner categories full access, it gives group users both read and execute access, and it denies access to users in the world category.
(DEFAULT_PROTECTION,S:RWED,O:RWED,G:RE,W:)

Creator ACE Adds an extra ACE to the ACL of a file created within the directory to which you assign the Creator ACE. The Creator ACE applies when the file being created is not owned by the user identification code (UIC) of the process creating the file, such as when the directory is owned by a resource identifier.
The following ACE, for example, specifies that any user creating a file in the directory will receive read, write, execute, and delete access to it:
(CREATOR,ACCESS=READ+WRITE+EXECUTE+DELETE)

The Creator ACE applies to directory files only.

Security Alarm ACE Allows you to request that a security alarm message be sent to the operator's terminal if an object is accessed in a particular way.
For example, the following ACE causes an alarm message whenever a particular file is successfully read:
(ALARM=SECURITY,ACCESS=SUCCESS+READ)

The security Alarm ACE has no effect unless ACL alarms are enabled with the following command:
$ SET AUDIT/ALARM/ENABLE=(ACL)

Security Audit ACE Specifies the access criteria that cause a security alarm message be sent to the system security audit log file if an object is accessed in a particular way.
For example, the following ACE causes an alarm message whenever a particular file is successfully read:
(AUDIT=SECURITY,ACCESS=SUCCESS+READ)

A message is recorded only if ACL audits are enabled with the DCL command SET AUDIT/AUDIT/ENABLE=ACL.

Subsystem ACE Grants additional identifiers to a process while it is running the image to which the Subsystem ACE applies. Users with execute access to the image can access objects that are in the protected subsystem, such as data files and printers, but only when they run the subsystem image. The Subsystem ACE applies to executable images only.
For example, the following ACE adds the identifier ACCOUNTING to processes that are executing a particular subsystem image. The identifier entitles the processes to access objects owned by the subsystem.
(SUBSYSTEM, IDENTIFIER=ACCOUNTING)

ACE	Description
Identifier ACE	Controls the types of access allowed to specific users based on the user's identification. Each Identifier ACE includes one or more rights identifiers and a list of the types of access the user holding the identifier has permission to exercise. See Section 11.5.2 for a summary of identifiers. For example, the following ACE grants the user Jones read, write, and execute access to an object: (IDENTIFIER=[ACCOUNTING,JONES],ACCESS=READ+WRITE+EXECUTE)
Default Protection ACE	Allows you to specify a protection code for a directory file that is propagated to all files created within that directory and its subdirectories. For example, the following ACE assigns a protection code to newly created files in a directory. The code gives users in the system and owner categories full access, it gives group users both read and execute access, and it denies access to users in the world category. (DEFAULT_PROTECTION,S:RWED,O:RWED,G:RE,W:)
Creator ACE	Adds an extra ACE to the ACL of a file created within the directory to which you assign the Creator ACE. The Creator ACE applies when the file being created is not owned by the user identification code (UIC) of the process creating the file, such as when the directory is owned by a resource identifier. The following ACE, for example, specifies that any user creating a file in the directory will receive read, write, execute, and delete access to it: (CREATOR,ACCESS=READ+WRITE+EXECUTE+DELETE) The Creator ACE applies to directory files only.
Security Alarm ACE	Allows you to request that a security alarm message be sent to the operator's terminal if an object is accessed in a particular way. For example, the following ACE causes an alarm message whenever a particular file is successfully read: (ALARM=SECURITY,ACCESS=SUCCESS+READ) The security Alarm ACE has no effect unless ACL alarms are enabled with the following command: $ SET AUDIT/ALARM/ENABLE=(ACL)
Security Audit ACE	Specifies the access criteria that cause a security alarm message be sent to the system security audit log file if an object is accessed in a particular way. For example, the following ACE causes an alarm message whenever a particular file is successfully read: (AUDIT=SECURITY,ACCESS=SUCCESS+READ) A message is recorded only if ACL audits are enabled with the DCL command SET AUDIT/AUDIT/ENABLE=ACL.
Subsystem ACE	Grants additional identifiers to a process while it is running the image to which the Subsystem ACE applies. Users with execute access to the image can access objects that are in the protected subsystem, such as data files and printers, but only when they run the subsystem image. The Subsystem ACE applies to executable images only. For example, the following ACE adds the identifier ACCOUNTING to processes that are executing a particular subsystem image. The identifier entitles the processes to access objects owned by the subsystem. (SUBSYSTEM, IDENTIFIER=ACCOUNTING)

See the OpenVMS System Management Utilities Reference Manual for a complete description of each kind of ACE. The OpenVMS Guide to System Security provides further details on how to construct and apply ACEs.

11.5.2 Types of Identifiers

An Identifier ACE can contain different types of identifiers. Any of these identifiers is an alphanumeric string of 1 to 31 characters with at least one alphabetic character. Valid characters include numbers 0 to 9, characters A to Z, the dollar sign ($), and the underscore (_). The following table lists each type of identifier: `

Type Description Example

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. [GROUP1,JONES]
[JONES]
GROUP1
JONES

General identifiers Defined by the security administrator. SALES
RESERVE_DESK

Environmental identifiers Describe different types of users based on their initial entry into the system. These identifiers are automatically created by the system. BATCH, NETWORK
INTERACTIVE
LOCAL, DIALUP
REMOTE

Facility identifiers Defined by a facility during installation RDB$ENTRY

Type	Description	Example
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.	[GROUP1,JONES] [JONES] GROUP1 JONES
General identifiers	Defined by the security administrator.	SALES RESERVE_DESK
Environmental identifiers	Describe different types of users based on their initial entry into the system. These identifiers are automatically created by the system.	BATCH, NETWORK INTERACTIVE LOCAL, DIALUP REMOTE
Facility identifiers	Defined by a facility during installation	RDB$ENTRY

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

11.6 Assigning ACLs

You can place ACLs on the following object classes:

Capability
Common event flag cluster
Device
File
Group global section
Logical name table
Queue
Resource domain
Security class
System global section
Volume

Typically, ACLs are used when you want to provide access to an object for some, but not all, users, or if you want to deny access to specific, unprivileged users. When the operating system receives a request for access to an object having an ACL, it searches each access control list entry in the ACL, stopping at the first match. If another match occurs in the ACL, it has no effect. Therefore, ACEs granting or denying access to a protected object for specific users should appear in the ACL before ACEs identifying broader classes of users.

11.7 Using the ACL Editor

The access control list editor (ACL editor) is a screen-oriented editor used to create and maintain ACLs. Use the ACL editor to define an ACL for a protected object or to edit an existing ACL.

You can use either the EDIT/ACL command or the SET SECURITY/EDIT command to invoke the ACL editor. In the command line, specify the name of the object whose ACL you want to create or modify. For example, the following command invokes the ACL editor to create an ACL for the file INVENTORY.DAT:

$ EDIT/ACL INVENTORY.DAT

If the object whose ACL you want to create or modify is not a file, you must specify the type of object with the /CLASS qualifier. For example, the following command invokes the ACL editor to create an ACL for the disk DOCD$:

$ EDIT/ACL/CLASS=DEVICE DOCD$

You can invoke the ACL editor to modify an existing ACL or to create a new ACL on the object. If an object has an ACL, the ACL will appear on the screen when the ACL editor is invoked.

The ACL editor can be invoked from within a program written in any OpenVMS common language that generates calls using the OpenVMS calling standard. Refer to the OpenVMS Utility Routines Manual for more information on using the callable interface to the ACL editor.

11.7.1 Adding an Identifier ACE

An Identifier ACE controls the types of access allowed to a particular user or group of users. It has the following format:

(IDENTIFIER=identifier[,options][,access])

For example, the following ACE grants user Pat, who is identified by the UIC identifier [SALES,PAT], read, write, and execute access to a file. The ACL denies Pat delete and control access because it omits them from the access statement.

(IDENTIFIER=[SALES,PAT],ACCESS=READ+WRITE+EXECUTE)

  6017P035.HTM
  OSSG Documentation
  22-NOV-1996 14:22:07.38

Legal