OpenVMS Guide to System Security

To establish a proxy login on the local node, the remote user must have a default proxy account on the local node that maps to a local user name. The remote user assumes the same file access, rights, and privileges as the local user name. You can use the proxy login capability to increase security because it minimizes the need to specify explicit access control information in node specifications passed over the network or stored in command procedures.

Note that network applications can also be assigned proxy login access.

The use of access control strings in not permitted in an evaluated configuration. Proxy login accounts should be used in the evaluated configuration.

12.2.3 Using Default Application Accounts

Another form of access control specific to network applications is default account information used by inbound connects from remote nodes that send no access control information. Because the remote node supplies no access control information, the local node uses the default information you specify for the application to make the connection.

You can use the following command to store default access control information about the application in the network configuration database:

NCP> SET OBJECT FAL USER JILL

Section 12.2.2 defines the concept of proxy logins. You can authorize proxy access when you encounter situations where users on different nodes or in different groups want to share files on your system and you are reluctant to give out passwords or to set the directory and file protection to W:RWE. With proxy logins, there is no need to embed passwords in commands to copy a file across the network. There is also no need to allow world read access to a file for file transfers. The user enters the following form of the DCL command COPY to a default proxy account:

COPY remotenode::file-spec file-spec 

To copy a file over the network using proxy access from an account other than the default, the user includes the name of the proxy account in the access control string of the DCL command, as follows:

COPY remotenode"proxyacct"::file-spec file-spec 

Proxy access is a selective merging of the authorization databases of the affected systems. Therefore, the security is only as good as the security of the least secure node.

Although proxy access eliminates passwords going over the network, it is possible for a personal computer to bypass the proxy login mechanism by impersonating one of the authorized nodes. For this reason, implement the following procedures:

• Do not enable incoming proxy access to sensitive data.
• Set up nonprivileged proxy accounts. If an account does need privilege, be sure those privileges cannot damage your system. (This practice provides a shield between systems in a network in the event one node is penetrated. The fact that proxy logins provide admittance only to nonprivileged accounts at other nodes may help contain the extent of damage if one system in the network is penetrated.) If your site has high security requirements, do not grant network or remote access to privileged user names.
• Extend proxy access only to nodes that are always or almost always on the network. (It is easier for an intruder to impersonate a node when it is off the network.) You must create a balance between using proxies and having access control strings with passwords traveling over the network. A workstation or personal computer on the network that is capable of impersonating a node is also capable of monitoring network messages and thus capturing passwords. Ultimately, you must ensure that all nodes connected to your local network have some level of trustworthiness.
• Exercise caution when authorizing users. Ideally, you should receive a formal authorization request from the security administrator at the remote site.
• Examine any login command procedures for a proxy account. Make certain that they follow the recommendations in Section 7.2.4.2 for login command procedures in captive accounts. Login command procedures should reside in a well-protected directory owned by a user other than the owner of the proxy account. They should prohibit write access for those who use the account.

If a remote user's connection request does not contain access control information, the following conditions must be met for proxy access to be approved:

• The proxy database on the target node must contain a source node's node synonym and source user name combination that matches the remote source node's node synonym and source user name. In Example 12-1, for example, the security administrator adds an proxy for KMahogany. KMahogany must access the proxy account from node Birch.
• The target node's user authorization file must contain a source user name that matches the proxy database entry's target source user name. Example 12-1 assumes that the SYSUAF.DAT file on node Birch has a user authorization record for KMahogany.
• Incoming proxy access must be enabled for the target node in the configuration database. See Section 12.3.2.1.
• Incoming proxy access must be enabled for the target application in the configuration database. See Section 12.3.2.1.
• Outgoing proxy must be enabled on the originating node for the node itself and for all applications that expect to use proxy.

You can control the use of proxy logins at the local node. Use AUTHORIZE to create and modify the permanent proxy database.

The default network proxy authorization file is NET$PROXY.DAT. However, AUTHORIZE maintains the file NETPROXY.DAT for compatibility, for support of many layered products, and for translation of DECnet for OpenVMS (Phase IV) node names.

Each network proxy entry can map a single remote user to multiple proxy user names on the local node (one default proxy user name and up to fifteen additional proxy user names). If you are going to have access to more than one proxy account from the same node and login name, indicate which proxy account should be the default. The proxy database entry identifies the user in the form of nodename::username or nodename::[group,member].

For example, to create a proxy file at a local node and add a default proxy entry mapping user Martin on remote node Boston to user Allen at the local node, enter the following commands:

$ SET DEFAULT SYS$SYSTEM
$ RUN AUTHORIZE
UAF> CREATE/PROXY
UAF> ADD/PROXY BOSTON::MARTIN ALLEN/DEFAULT
UAF> EXIT

Similarly, the system manager at a remote node can create and maintain a proxy database of network users having proxy access to specific accounts on that node. Table 12-1 summarizes AUTHORIZE commands used to manage the proxy database.

Table 12-1 AUTHORIZE Commands for Managing Network Proxy Access

Command	Argument	Description
ADD/PROXY	node::remoteuser localuser[,...]	Adds proxy access for the specified user.
CREATE/PROXY		Creates a network proxy authorization file.
LIST/PROXY		Creates a listing file of all proxy accounts and all remote users with proxy access to the accounts.
MODIFY/PROXY	node::remoteuser	Modifies proxy access for the specified user.
REMOVE/PROXY		Deletes proxy access for the specified user.
SHOW/PROXY	* node::remoteuser	Displays proxy access allowed for the specified user.

12.3.2.1 Enabling and Disabling Incoming Proxy Access

You can control proxy access to your node and to particular applications.

Controlling Proxy Access to a Node

To accept proxy connections to your node, set the incoming proxy attribute in the executor database in the following way:

NCP> SET EXECUTOR INCOMING PROXY ENABLE

To deny proxy connections to your node, set the outgoing proxy attribute in the following way:

NCP> SET EXECUTOR INCOMING PROXY DISABLE

If proxy access to the node is disabled, the system ignores any proxy connection request.

A comparable set of steps is necessary on the originating node so that proxy data is transmitted in the connect request message. Set proxy attributes for both the node and for all applications that expect to use proxy, for example:

NCP> SET EXECUTOR OUTGOING PROXY ENABLE
NCP> SET OBJECT MAIL PROXY BOTH
NCP> SET OBJECT MAIL PROXY INCOMING
NCP> SET OBJECT MAIL PROXY OUTGOING

In general, enabling outgoing proxy is a good idea, even if the target node does not enable proxy for the object, because enabling outgoing proxy puts the originating user name in the connect message. Thus the user name is available for accounting and audit logs on the target node. Be aware that a small number of DECnet applications depend on the nonproxy form of the connect message (for example, some use the connect message space for application information rather than user names) and do not function if outgoing proxy is enabled.

Controlling Proxy Access to an Application

To allow proxy access to a particular application, you must enable the proxy access for both the node and the application. In addition, specify the name of the application in the SET OBJECT command. For example, the following enables proxy access to the application NML:

NCP> SET EXECUTOR INCOMING PROXY ENABLE
NCP> SET OBJECT NML INCOMING PROXY ENABLE

To disable proxy access to an application, identify the application in the SET OBJECT command, and set the incoming proxy attribute to disable. For example, the following disables proxy access to the application FAL:

NCP> SET OBJECT FAL INCOMING PROXY DISABLE

If incoming proxy is enabled for the application but the proxy access for the node is disabled, the system in effect ignores any proxy access request to the application.

12.3.2.2 Removing Proxy Access

Remove proxy access to the system when it is no longer needed. Invoke AUTHORIZE, and enter the following command to remove proxy access:

UAF> REMOVE/PROXY BOSTON::MARTIN

When you want to set up a proxy account on your node for use by one or more users at other nodes, you must perform the following steps. Refer to the security guidelines listed in Section 12.3.1 as you create the account.

1. Define the purpose of the account, its name, and which network users will be admitted.
2. Create the local account, if necessary, with AUTHORIZE; if the account already exists, make sure it is restricted and defined as /NOINTERACTIVE, /NOBATCH, /NETWORK.
3. Review the privileges on the account. Generally avoid granting privileges to proxy login accounts.
4. Create the network proxy authorization file, if necessary, with the AUTHORIZE command CREATE/PROXY. (The system usually creates it automatically.)
5. Allow as many remote users as necessary access to the proxy account with the AUTHORIZE command ADD/PROXY.
6. Check the default protection on the directory, and customize it as necessary.
7. Examine any login command procedure specified by the /LGICMD qualifier to the ADD command. In captive accounts, make certain that the login command procedure follows the recommendations in Section 7.2.4.2. It should reside in a well-protected directory owned by a user other than the owner of the proxy account. It should prohibit write access for those who use the account.
8. Notify the security administrator at the remote node about which users from that node have been authorized for access to your node.

In Example 12-1, the security administrator at the node WALNUT wants to create a general access account called GENACCESS. At the same time the administrator wants to take steps to allow proxy logins by three users from the node BIRCH: KMahogany, PSumac, and WPine, as well as two users from the node WILLOW: RDogwood and WCherry. No network proxy authorization file currently exists.

Example 12-1 Sample Proxy Account

$ SET DEFAULT SYS$SYSTEM
$ RUN AUTHORIZE
UAF> ADD GENACCESS /PASSWORD=WHYNADGUM/UIC=[236,043] -
_UAF> /DEVICE=STAFFDEV/DIRECTORY=[GENACCESS] -
_UAF> /OWNER="Security Mgmt"/ACCOUNT=SEC -
_UAF> /FLAGS=(DISWELCOME,DISNEWMAIL,GENPWD,DISMAIL) -
_UAF> /NOBATCH/NOINTERACTIVE/MAXDETACH=8 -
_UAF> /LGICMD=LOGIN/MAXACCTJOBS=10
 
%UAF-I-ADDMSG, user record successfully added
%UAF-I-RDBADDMSGU, identifier GENACCESS value [000236,000043] 
added to rights database
%UAF-I-RDBADDMSGU, identifier SEC value [000236,177777] added to 
rights database
UAF> CREATE/PROXY
UAF> ADD/PROXY BIRCH::KMAHOGANY GENACCESS/DEFAULT
%UAF-I-NAFADDMSG, proxy from OMNI:.BOSTON.BIRCH::KMAHOGANY to 
GENACCESS added
UAF> ADD/PROXY BIRCH::PSUMAC GENACCESS/DEFAULT
%UAF-I-NAFADDMSG, proxy from OMNI:.BOSTON.BIRCH::PSUMAC to 
GENACCESS added 
UAF> ADD/PROXY BIRCH::WPINE      GENACCESS/DEFAULT
%UAF-I-NAFADDMSG, proxy from OMNI:.BOSTON.BIRCH::WPINE  to 
GENACCESS added 
UAF> ADD/PROXY WILLOW::RDOGWOOD   GENACCESS/DEFAULT
%UAF-I-NAFADDMSG, proxy from OMNI:.BOSTON.WILLOW::RDOGWOOD to 
GENACCESS added                                    
UAF> ADD/PROXY WILLOW::WCHERRY    GENACCESS/DEFAULT
%UAF-I-NAFADDMSG, proxy from OMNI:.BOSTON.WILLOW::WCHERRY to 
GENACCESS added                                    
 
UAF> SHOW/PROXY *::*
 Default proxies are flagged with a (D)
 
OMNI:.BOSTON.BIRCH::KMAHOGANY
     GENACCESS (D)
 
OMNI:.BOSTON.BIRCH   ::PSUMAC
     GENACCESS (D)
 
OMNI:.BOSTON.BIRCH   ::WPINE
     GENACCESS (D)
 
OMNI:.BOSTON.WILLOW  ::RDOGWOOD
     GENACCESS (D)
 
OMNI:.BOSTON.WILLOW  ::WCHERRY
     GENACCESS (D)
 
 
UAF> EXIT
{messages}
$ DIRECTORY/SECURITY SYS$STAFF:[000000]GENACCESS.DIR
   .
   .
   .
$ DIRECTORY/SECURITY SYS$STAFF:[GENACCESS]LOGIN.COM
   .
   .
   .

Network objects are system programs and user-written applications that permit communication among nodes in a DECnet network. You need to identify the set of network objects allowed access to your system, and set up the appropriate access controls for each object. The following mechanisms are available:

• DECnet object accounts These are individual accounts for specific network objects (for example, MAIL) automatically configured on your system. These provide more accountability of remote access to an object than the default DECnet account provides. (For example, an object can have a captive account with a login command procedure that grants or denies access to the object based on the remote node name or user name.)
• Default DECnet account This type of account allows all network objects general access to the system. It is appropriate for systems with low security requirements (for example, a local area network of systems located within a site with no outside connections or dialup lines). The default DECnet user name lets users perform certain network operations, such as the exchange of electronic mail between users on different nodes, without having to supply a user name and password. The default DECnet user name is also used for file operations when access control information is not supplied. For example, it lets remote users access local files on which the file protection has been set to allow world access. If you do not want remote users accessing your node, do not create a default DECnet user name. See Section 12.4.3 for information about removing default DECnet accounts.

You should understand the function of the network objects supplied with the OpenVMS operating system before you determine the access control to apply to them. This section provides a description of the most common network objects.

FAL

The file access listener (FAL) is the remote file access facility. FAL is an image that receives and processes remote file access requests for files at the local node.

Use of general FAL access is strongly discouraged. Open access allows general network access to any files marked world-accessible. It also allows remote users to create files in any directory with world write access.

Sites with high security requirements, or sites where it is difficult to recognize all the intended users, should not create a FAL account. To control which users gain access, these sites may establish one or more proxy accounts for specific purposes (see Section 12.3).

MAIL

MAIL is an image that provides personal mail services for OpenVMS systems. In most cases, allow the MAIL object general access to the system.

MIRROR

MIRROR is an image used for particular forms of loopback testing. For example, MIRROR is run during the DECnet phase of the UETP test package.

MOM

MOM is the Maintenance Operations Module. The MOM image downline loads unattended systems, transferring a copy of an operating system file image from an OpenVMS node to a target node. The MOM object is established during a system installation.

NML

NML is the network management listener. Remote users with access to NML can use NCP TELL commands to gather and report network information from your DECnet databases.

PHONE

PHONE is an image that allows online conversations with users on remote OpenVMS systems. Note that if you allow default DECnet access to PHONE, anyone in the network can get a list of users currently logged in to the local system and attempt a login using the list of user names.

TASK

Through the default DECnet account, the TASK object allows arbitrary command procedures (including those that might be used in intrusions) to be executed on your system.

Note that if you do not allow default DECnet access on your system or if you disable default DECnet access to the TASK object, you can allow remote user-written command procedures (tasks) to run on your system through the use of access control strings or proxy access.

VPM

VPM is the Virtual Performance Monitor Server. Access to VPM is required to use the cluster monitoring features of the Monitor utility (MONITOR).

12.4.2 Configuring Network Objects Manually

The command procedure NETCONFIG.COM configures the network objects on your system automatically, and the command procedure NETCONFIG_UPDATE.COM updates the network objects automatically.

If you choose not to use the command procedures, you can perform the following steps to allow network access to specific objects:

1. Create a top-level directory for each network object, and specify a unique owner UIC and group UIC. For example, the following command sequence creates a top-level directory for the MAIL object on the system disk:

   $ SET DEFAULT SYS$SPECIFIC:[000000]
   $ CREATE/DIRECTORY [MAIL$SERVER]/OWNER_UIC=[376,374]
   

   
   Table 12-2 lists the directory names, user names, and UICs used by the NETCONFIG.COM and NETCONFIG_UPDATE.COM command procedures to create accounts for specific network accounts. For consistency, you should specify the same information when manually creating network object accounts.
   Note that the MOM object is created by the operating system during installation.
2. Using AUTHORIZE, create an account for the object, and use a generated password. (Note that the user name and password that you specify must match the password defined for the object in the network database [described in step 3].)
   For example, the following command sequence sets up an account for the MAIL object:

   $ RUN SYS$SYSTEM:AUTHORIZE
   UAF> ADD MAIL$SERVER/OWNER=MAIL$SERVER DEFAULT -
   _UAF> /PASSWORD=MDU1294B/UIC=[376,374]/ACCOUNT=DECNET -
   _UAF> /DEVICE=SYS$SPECIFIC: /DIRECTORY=[MAIL$SERVER] -
   _UAF> /PRIVILEGE=(TMPMBX,NETMBX) /DEFPRIVILEGE=(TMPMBX,NETMBX) -
   _UAF> /FLAGS=(RESTRICTED,NODISUSER,NOCAPTIVE) /LGICMD=NL: -
   _UAF> /NOBATCH /NOINTERACTIVE
   

   
   The AUTHORIZE command SHOW MAIL$SERVER displays the network account set up for the MAIL object, as shown in Example 12-2.
3. Use the NCP DEFINE command to associate the user name and password of the account with the specified object in the network database, as follows:

   $ RUN SYS$SYSTEM:NCP
   NCP> DEFINE OBJECT MAIL USER MAIL$SERVER PASSWORD MDU1294B
   NCP> EXIT
   

4. Repeat steps 1 through 3 for each network object.
5. When finished, remove default DECnet access from the executor database, and remove the default DECnet account from the SYSUAF (see Section 12.4.3).
6. Finally, reboot the system to copy changes made to the permanent executor and object databases to the running system.

Table 12-2 lists the network object defaults.

Table 12-2 Network Object Defaults

Object Name	Directory and User (Account) Name	UIC
FAL	FAL$SERVER	[376,373]
MAIL	MAIL$SERVER	[376,374]
MIRROR	MIRRO$SERVER+	[376,367]
$MOM	VMS$COMMON:[MOM$SYSTEM]++	[376,375]
NML	NML$SERVER	[376,371]
PHONE	PHONE$SERVER	[376,372]
VPM	VPM$SERVER	[376,370]

Example 12-2 UAF Record for MAIL$SERVER Account

Username: MAIL$SERVER                   Owner:  MAIL$SERVER 
Account:  MAIL$SERVER DEFAULT           UIC:    [376,374] ([DECNET,MAIL$SERVER]) 
CLI:      DCL                           Tables: 
Default:  SYS$SPECIFIC:[MAIL$SERVER] 
LGICMD:   
Login Flags:  Restricted 
Primary days:   Mon Tue Wed Thu Fri Sat Sun 
Secondary days: 
Primary   000000000011111111112222  Secondary 000000000011111111112222 
Day Hours 012345678901234567890123  Day Hours 012345678901234567890123 
Network:  ##### Full access ######            ##### Full access ###### 
Batch:    -----  No access  ------            -----  No access  ------ 
Local:    -----  No access  ------            -----  No access  ------ 
Dialup:   -----  No access  ------            -----  No access  ------ 
Remote:   -----  No access  ------            -----  No access  ------ 
Expiration:            (none)    Pwdminimum:  6   Login Fails:     0 
Pwdlifetime:           (none)    Pwdchange:  (none) 
Last Login:            (none) (interactive), (none) (non-interactive) 
Maxjobs:         0  Fillm:        16  Bytlm:        12480 
Maxacctjobs:     0  Shrfillm:      0  Pbytlm:           0 
Maxdetach:       0  BIOlm:        12  JTquota:       1024 
Prclm:           0  DIOlm:         6  WSdef:          180 
Prio:            4  ASTlm:        16  WSquo:          200 
Queprio:         0  TQElm:        10  WSextent:         0 
CPU:        (none)  Enqlm:        20  Pgflquo:      25600 
 
Authorized Privileges: 
  TMPMBX NETMBX 
Default Privileges: 
  TMPMBX NETMBX 
 

The default DECnet account is appropriate for systems with low security requirements (see Section 12.4). If your site has moderate or high security requirements, you should remove default DECnet access to the system once you have set up accounts for individual network objects.

Warning

Before deleting your default DECNET account, as described in this section, use the NCP command SHOW KNOWN OBJECTS and the Authorize utility (AUTHORIZE) to verify that all network objects and layered products that use network objects have network accounts set up in the system user authorization file (SYSUAF.DAT). Otherwise, network objects and layered products that use network objects may not work as expected.

To do this, remove access to the DECNET account in the network configuration database, and delete the DECNET account from the SYSUAF.

Removing Default DECnet Access

Execute the following NCP commands to remove the default DECnet access from the network executor database:

NCP> DEFINE EXECUTOR NONPRIVILEGED USER DEFAULT_DECNET
NCP> PURGE EXECUTOR NONPRIVILEGED PASSWORD 

The DEFAULT_DECNET user specified in the first command is a nonexistent user account that is specified for auditing purposes only. (A network login failure message is written to the security audit log file each time access to your system is attempted through the [nonexistent] DEFAULT_DECNET account.)

Deleting the DECNET Account

Using AUTHORIZE, remove the DECNET account from SYSUAF, as follows:

$ SET DEFAULT SYS$SYSTEM
$ RUN AUTHORIZE
UAF> REMOVE DECNET
UAF> EXIT

Delete any files in the [DECNET] directory structure.

Modifying the Volatile Configuration Database

To have the change take effect immediately, modify the volatile database with the following NCP commands:

NCP> SET EXECUTOR NONPRIVILEGED USER DEFAULT_DECNET
NCP> CLEAR EXECUTOR NONPRIVILEGED PASSWORD

You can select specific privileges to control the use of DECnet objects that are specified during network configuration. In such instances, it becomes a privileged operation to connect to a privileged DECnet object or use an outgoing DECnet object.

For example, the following command establishes the requirement that users initiating a DECnet connection to the remote object MAIL must possess the OPER and SYSNAM privileges:

NCP> DEFINE OBJECT MAIL OUTGOING CONNECT PRIVILEGES OPER,SYSNAM

This mechanism is a useful way of limiting access to certain DECnet applications to privileged users or programs. However, in order to be effective, the privilege requirement must be imposed consistently on all nodes in the network.

12.5 Specifying Routing Initialization Passwords

Point-to-point connections are connections over synchronous and asynchronous lines. For point-to-point connections, especially over dialup lines, you can use routing initialization passwords to verify that the initiating node is authorized to form a connection with your node. Each end of a point-to-point circuit can establish a verifier to transmit to the other node and specify a verifier expected from the other node. Before the link is established, each node verifies that it received the expected verifier from the other node.

  6346P021.HTM
  OSSG Documentation
  22-NOV-1996 13:05:23.04

Copyright © Digital Equipment Corporation 1996. All Rights Reserved.

Legal