Document revision date: 15 July 2002

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.

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.

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

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

The following example shows the expanded expiration time field in the new SHOW INTRUSION output.

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

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

12.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). Compaq reserves group 1 and groups 300--377.

12.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:
  • 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

12.5 Creating Intra-Cluster Communications Security Objects

OpenVMS provides SYS$MANAGER:ICC$SYSTARTUP.COM. This command procedure allows you to customize the ICC characteristics by creating ICC security objects and adding additional registry tables.

The ICC$CREATE_SECURITY_OBJECT procedure creates permanent ICC security objects and optionally issues an initial SET SECURITY command for the object. Specify node::association to create a security object for an association before it exists. For example, specify MYNODE::BOB_SERVER. Use the special node name ICC$ to create a security object for an entry in the ICC clusterwide registry.

Before creating an association through ICC, you need the OPEN security attribute on the node::association pair. A security object created by ICC$CREATE_SECURITY_OBJECT is not deleted until the system reboots.

The ability to connect to an association is controlled by the ACCESS security attribute on the security object.

Every process using ICC must open an association. If you have SYSNAM privilege, you can open associations without calling ICC$CREATE_SECURITY_OBJECT, however the object is not permanent. No privileges are required, therefore anyone can create access named ICC$pid* (for example, ICC$20203F9A_FOO).

ICC$CREATE_SECURITY_OBJECT can also be used to regulate creating names in the ICC clusterwide registry using the special node name ICC$. For creating names in the registry, the security access attributes OPEN and CONTROL are relevant.

Note that SYS$MANAGER: also contains file SYS$SYSTARTUP.TEMPLATE so that you can customize the procedure to your specific requirements.

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

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

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

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

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

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

12.8 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 about using the callable interface to the ACL editor.

	privacy and legal statement
6017PRO_054.HTML