Updated: 24 May 2001

OpenVMS Guide to System Security

When writing captive command procedures for your site, be sure to observe the following guidelines:

• Use the DCL command READ/PROMPT in command procedures. For example, to request the user to enter the date, enter the following command in the command procedure:

  READ/PROMPT="Enter date: " SYS$COMMAND DATE

• Avoid use of the INQUIRE command in a captive command procedure. It produces an error that, if unhandled by a previous ON declaration, results in deletion of the process.
• When user input is required, never execute it directly. First compare it to what is expected, and screen for illegal characters such as apostrophe ('), at sign (@), dollar sign ($), quotation mark ("), ampersand (&), and hyphen (-).
• Avoid any use of the construction 'x, where x contains a string entered by the user. Never permit a restricted command procedure to attempt an evaluation of a symbol that the user enters. Use of lexical functions could break the command procedure.
• Avoid executing a line in a captive command procedure that contains the characters @TT:.
• Put Audit ACEs on the captive command procedure and its home directory to detect any modification of the file. See Section 9.2.1.2 for more information on Audit ACEs.
• If the captive account user is allowed to create or perform other operations on files, make certain that write access to the login command procedure and its directory is denied. (The user does need execute access.)
  If the function of the command procedure requires text preparation, you may need to give users access to a text editor. Use caution, however. Editors such as TECO or DECTPU can be dangerous because users can manipulate files and exit from the editor to the DCL interface. When designing this environment, remember that most text editors are capable of reading and writing files (within the access rights of the account). Provide an editor that gives users the tools they require but does not allow them to escape from the captive environment.

Example 7-3 and Example 7-4 provide sample command procedures for privileged and unprivileged accounts.

Example 7-3 Sample Captive Procedure for Privileged Accounts

$ if f$mode() .nes. "INTERACTIVE" then $logout $ term = f$logical("SYS$COMMAND") $ if f$locate("_T", term) .eq. 0 then $goto allow $ if f$locate("_OP",term) .ne. 0 then $logout $allow: $ set control=(y,t)

Example 7-4 Sample Captive Command Procedure for Unprivileged Accounts

$ deassign sys$input $ previous_sysinput == f$logical("SYS$INPUT") $ on error then goto next_command $ on control_y then goto next_command $ set control=(y,t) $ $next_command: $ on error then goto next_command $ on control_y then goto next_command $ $ if previous_sysinput .nes. f$logical("SYS$INPUT") then deassign sys$input $ read/end=next_command/prompt="$ " sys$command command $ command == f$edit(command,"UPCASE,TRIM,COMPRESS") $ if f$length(command) .eq. 0 then goto next_command $ $ delete = "delete" $ delete/symbol/local/all $ if f$locate("@",command) .ne. f$length(command) then goto illegal_command $ if f$locate("=",command) .ne. f$length(command) then goto illegal_command $ if f$locate("F$",command) .ne. f$length(command) then goto illegal_command $ verb = f$element(0," ",command) $ $ if verb .eqs. "LOGOUT" then goto do_logout $ if verb .eqs. "HELP" then goto do_help $ $ write sys$output "%CAPTIVE-W-IVVERB, unrecognized command \",verb,"\" $ goto next_command $ $illegal_command: $ write sys$output "%CAPTIVE-W-ILLEGAL, bad characters in command line" $ goto next_command $ $do_logout: $ logout $ goto next_command $ $do_help: $ define sys$input sys$command $ help $ goto next_command

7.2.5 Restricted Accounts

Certain limited-access accounts require a less restrictive environment than captive accounts. Accounts under which network objects run, for example, require temporary access to DCL. Such accounts must be set up as restricted accounts, not captive accounts. Restricted accounts are indistinguishable from regular accounts once the login sequence finishes. The purpose behind restricted accounts is to ensure a trusted login wherein SYLOGIN, LOGIN, and their descendants execute completely.

Define a restricted account with the Authorize utility by including the following qualifier when creating the account:

/FLAGS=(RESTRICTED)

This flag ensures that the account is noted as restricted. A restricted account provides the same features as those listed for a captive account in Section 7.2.4 except that restricted accounts allow the user access to the DCL command level following the execution of the system and process login command procedures.

Sometimes it is appropriate to allow the user to enter the Ctrl/Y key sequence after the command procedure starts. For example:

• You may want to provide users with a Ctrl/Y feature at points during the execution of the restricted login command procedure. Include ON CONTROL_Y commands in the procedure where you want to test for the Ctrl/Y features, as shown in Example 7-4.
• You may have a restricted command procedure that ultimately turns control over to the user. For example, consider a SYLOGIN.COM command procedure that performs additional security validation; its execution should be guaranteed to ensure its effectiveness. However, once SYLOGIN.COM has done its job, control can be passed to the user. To do this, mark the account as restricted, and enter the DCL command SET CONTROL=Y when you are ready to release control to the user.

To force individuals at specific terminals to log in to an application program, create a separate captive account for the application. Then set up automatic logins to the new account for the desired users using the System Management utility (SYSMAN).

Once you set up a terminal for automatic login, it can be used only for the designated account. This is most useful for applications terminals used by people who may be unfamiliar with computers.

The automatic login feature suppresses the user name prompt. All other login features (system password, primary and secondary passwords, and messages) function normally, if enabled.

Passwords are optional. If you want the account to be open to all users where the terminals are located, eliminate the password. When no password is required, the user has no data to enter at login. The operating system logs the terminal in automatically in response to the Break key or the Return key and immediately enters the application if the account is under the control of a captive login command procedure.

The automatic login file (ALF) lists the terminals and the users who are authorized to access the application account. However, automatic login accounts are potentially accessible from terminals and sources other than the terminals listed in the ALF file and, therefore, require protection, especially if they have no password. Use the following precautions:

• Restrict network and dialup access, as appropriate, with the AUTHORIZE qualifiers /NODIALUP, /NONETWORK, and /NOREMOTE.
• Set the AUTOLOGIN flag in the account's UAF record. This flag makes the account available only by autologin, batch, and network proxy.

Guest accounts are forms of captive or restricted accounts that allow multiple remote users access to resources on your system through a common account. For example, users across the network may need access to your system to report problems or to read corporate memos.

Compaq does not recommend the practice of setting up guest accounts. Guest accounts, however unprivileged, offer malicious users a chance to compromise your system security. Most needs for a guest account can be handled by special proxy login accounts, which should also be limited-access accounts.

If you still need a guest account, take the following steps to make the account secure:

• Use an obscure password for the guest account. Change the password frequently. Never use easily guessed account name and password combinations such as GUEST/GUEST or USER/USER.
• Maintain a list of people allowed to use the account. (Changing the password regularly helps you keep this list current.)
• Set up the guest account in a separate UIC group. Make sure that the account is not a member of the system group.
• Place the default login command procedure in the directory SYS$MANAGER by using the AUTHORIZE command MODIFY, as follows:

  MODIFY guest-account/LGICMD=SYS$MANAGER:filename.COM

• Make the guest account restricted or captive by setting the AUTHORIZE qualifiers /FLAGS=RESTRICTED or /FLAGS=CAPTIVE, respectively.
• If the guest account is set up as a restricted account, limit the number of subprocesses that the account can create to 0 using the AUTHORIZE qualifier /PRCLM=0. (Ensure that the system parameter PQL_MPRCLM is also set to 0.)
• Assign the guest account only TMPMBX privilege.
• To handle error conditions, include the following commands in the default login command procedure:

  SET ON SET NOCONTROLY ON ERROR THEN LOGOUT/BRIEF

• If the system has LOGOUT defined as a global symbol and points to a command procedure (enter the DCL command SHOW SYMBOL LOGOUT to confirm this), include the following DCL command in the default login command procedure for the account:

  DELETE/SYMBOL LOGOUT/GLOBAL

  
  This command eliminates the possibility that the user could break the restricted account at logout time by pressing Ctrl/Y.

• To prevent outsiders from misusing your system resources through the submission of batch jobs under the guest account, include the AUTHORIZE qualifier /NOBATCH when you create the account.
• Limit the disk quota for the guest account UIC to the amount needed.
• Do not allow the DCL command INQUIRE to appear in any of the command procedures.

Generally, proxy login accounts should be set up as restricted accounts. Proxy login accounts permit remote users to access a local account without specifying a password. Section 12.3.3 describes proxy login accounts. Note that many recommendations are the same as those for restricted accounts.

7.2.9 Externally Authenticated Accounts

Externally authenticated accounts are those that are marked with the EXTAUTH flag in the user's SYSUAF record. This enables these users to log in at the OpenVMS login prompt using their external user IDs and passwords. See Section 7.4 for more information on external authentication.

7.3 Using Passwords to Control System Access

A site needing average security protection always requires use of passwords. Sites with more security needs frequently impose a generated password scheme (see Section 7.3.2.4) and possibly system passwords as well.

This section describes password management.

7.3.1 Types of Passwords

With the exception of an automatic login account, all users must have at least one password to log in. Sites with moderate or high security requirements may impose additional passwords (see Table 3-2).

Externally authenticated users enter their external password at the OpenVMS password prompt. See Section 7.4 for more information.

This section explains how to assign passwords using DCL and AUTHORIZE commands.

7.3.1.1 Primary Passwords

When you open an account for a new user with AUTHORIZE, you must give the user a user name and an initial password. When you assign temporary initial passwords, observe all guidelines recommended in Section 3.8. Avoid any obvious pattern when you assign passwords. You may want to use the automatic password generator.

To use the automatic password generator while using AUTHORIZE to open an account, add the /GENERATE_PASSWORD qualifier to either the ADD or the COPY command. The system responds by offering you a list of automatically generated password choices. Select one of these passwords, and continue setting up the account.

Passwords you specify with AUTHORIZE are defined as expired by default. This forces the user to change the initial password when first logging in. See Section 7.3.2 for more information. Be sure to include information on the first login in your user training so that users know what to expect. If you do not want the password you define with AUTHORIZE to be pre-expired, add the qualifier /NOPWDEXPIRED when entering the password. This is necessary for accounts when users are not permitted to set their own password.

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

(pre-expired)

7.3.1.2 System Passwords

Section 3.2.1 introduces system passwords, which control access to particular terminals. System passwords are used to control access to terminals that might be targets for unauthorized use, as follows:

• All terminals using dialup lines or public data networks for access
• Terminals on lines that are publicly accessible and not tightly secured, such as those in computer laboratories at universities
• Terminals not frequently inspected
• Terminals intended for use only as spare devices
• Terminals you want to reserve for security operations

Execute the following steps to to implement system passwords:

1. Establish a record in the SYSUAF database for a system password by invoking the Authorize utility and entering the following command:

   UAF> MODIFY/SYSTEM_PASSWORD=password

   Note You only need to establish a record in the SYSUAF database the first time a system password is set up on the system. However, if no record is present,the SET PASSWORD/SYSTEM command returns the following error: %SET-F-UAFERR, error accessing authorization file -RMS-E-RNF, record not found

2. Decide which terminals require system passwords. Then, for each terminal, enter the DCL command SET TERMINAL/SYSPWD/PERMANENT. When you are satisified that you have selected the right terminals, incorporate these commands into SYS$MANAGER:SYSTARTUP_VMS.COM so that the terminal setup work is done automatically at system startup. You can remove the restriction on a terminal at any time by invoking the DCL command SET TERMINAL/NOSYSPWD/PERMANENT for that terminal.
3. Choose a system password, and implement it with the DCL command SET PASSWORD/SYSTEM, which requires the SECURITY privilege. This command prompts you for the password and then prompts you again for verification, just as for user passwords. To request automatic password generation, include the /GENERATE qualifier.

To enable the use of the system password for the remote class of logins (those accomplished through the DCL command SET HOST), set the appropriate bit in the default terminal characteristics parameter by using AUTOGEN. This is bit 19 (hexadecimal value 80000) in the parameter TTY_DEFCHAR2. Note that if you set this bit, you must invoke the DCL command SET TERMINAL/NOSYSPWD/PERMANENT to disable system passwords for each terminal where you do not want the feature. (As before, consider placing the SET TERMINAL commands you have tested in SYS$MANAGER:SYSTARTUP_VMS.COM.) Then follow the previously defined steps to set the system password.

When choosing a system password, follow the recommendations presented in Section 3.8. Choose a string of characters and digits, with a minimum length of 6, that is not a valid word. Although the system password is not subject to expiration, change the password frequently. Always change the system password as soon as a person who knows the password leaves the group. Share the system password only with those who need to know.

The system password is stored in a separate UAF record and cannot be displayed. The DCL command SET PASSWORD/SYSTEM (the normal means of setting and changing the system password) requires that you enter the old system password before changing it. Use the AUTHORIZE command MODIFY/SYSTEM_PASSWORD to change the system password without specifying the old password, as shown in the following command:

UAF> MODIFY/SYSTEM_PASSWORD=ABRACADABRA

The primary function of the system password is to form a first line of defense for publicly accessible ports and to prevent potential intruders from learning the identity of the system. However, requiring system passwords can appear confusing when authorized users are unaware that they are required on certain terminals. To avoid false reports of defective terminals or systems, inform your users which terminals allocated for their use require system passwords.

Where system passwords are not applied to either control access through dialup lines or on publicly accessed lines, few people may know the system password. Operations are hampered if the personnel who know the password are unavailable, incapacitated, or forget the password. Solve this problem by invoking AUTHORIZE and entering the MODIFY/SYSTEM_PASSWORD command. SYSPRV privilege is required.

7.3.1.3 Secondary Passwords

Sites with high-level security concerns can require a second password on user accounts. Typically, the user does not know the secondary password, and a supervisor or other key person must be present to supply it. For certain applications, the supervisor may also decide to remain present while the account is in use. The effectiveness of a secondary password depends on the trustworthiness of the supervisor who supplies it because the supervisor can remove the secondary password by changing it to a null string.

Although the use of dual passwords is cumbersome, they do offer the following advantages:

• When used on a widespread basis, dual passwords help verify the identity of each user at login time because the supervisor or other key person can check each user.
• When used in limited cases, dual passwords single out accounts that can be logged in to only when two persons are present.
• Dual passwords also prevent the use of access control strings when users access accounts through DECnet software.

Sites with medium security requirements may use dual passwords as a tool when there are unexplained intrusions after the password has been changed and use of the password generator has been enforced. Select problem accounts, and make them a temporary target of this restriction. If the problem goes away when you institute personal verification through the secondary password, you know you have a personnel problem. Most likely, the authorized user is revealing the password for the account to one or more other users who are abusing the account.

Implement dual passwords with the AUTHORIZE qualifier /PASSWORD. For example, to impose dual passwords on a new account, invoke AUTHORIZE and use the following form of the ADD command:

ADD newusername /PASSWORD=(primarypwd, secondarypwd)

To impose a secondary password on an existing account, use the following form of the MODIFY command:

MODIFY username /PASSWORD=("", secondarypwd)

This command does not affect the primary password that already exists for the account but adds the requirement that a secondary password be provided at each subsequent login. The secondary password acquires the same password lifetime and minimum length values in effect for the primary password. If the /FLAGS=GENPWD qualifier has been specified for this account, the secondary password can be changed only under the control of the automatic password generator. You cannot use wildcards in the user name parameter to apply a secondary password to multiple users with a single command.

Copyright © Compaq Computer Corporation 1998. All rights reserved. Legal

6346PRO_014.HTML