OpenVMS Guide to System Security

To achieve data consistency within the cluster, a site needs to:

• Maintain a common set of data, as described in Section 11.2.1, Section 11.2.2, and Section 11.2.3
• Execute changes to system parameters consistently When changing any LGI system parameters, use the System Management utility (SYSMAN) (see Section 11.7).

The easiest way to ensure a single security domain is to maintain a single copy of each of the files listed in Table 11-1 on one or more cluster-mounted disks. As soon as any required file is created on one node, it must be created or commonly referenced on all remaining cluster members. When a cluster is configured with multiple system disks, system logical names can be used to ensure that only a single copy of each file exists.

The files in Table 11-1 contain data that must be synchronized. If your site chooses to maintain multiple versions of these files, you must synchronize the data, as Section 11.2.3 explains.

Table 11-1 System Files That Must Be Common in a Cluster

File	Description
NETOBJECT.DAT	Contains the DECnet object database. Among the information contained in this file is the list of known DECnet server accounts and passwords.
NETPROXY.DAT NET$PROXY.DAT	Contains the network proxy database. This file is maintained by the Authorize utility (AUTHORIZE).
QMAN$MASTER.DAT	Contains the master queue manager database. This file contains the security information for all shared batch and print queues. A single copy of this file must be maintained on a shared disk if two or more nodes intend to participate in a shared queuing system.
RIGHTSLIST.DAT	Contains the rights identifier database. This file is maintained by AUTHORIZE and by various rights identifier system services.
SYSALF.DAT	Contains the system autologin file. This file is maintained by the System Management utility (SYSMAN).
SYSUAF.DAT	Contains the system user authorization file. This file is maintained by AUTHORIZE and modifiable through the Set User Authorization Information ($SETUAI) system service.
SYSUAFALT.DAT	Contains the system alternate user authorization file. This file serves as a backup to SYSUAF.DAT and is enabled through the SYSUAFALT system parameter.
VMS$OBJECTS.DAT	Contains the cluster-visible object database. Among the information contained in this file are the security profiles for all cluster-visible objects.

11.2.2 Recommended Common System Files

Although Digital does not require that the files listed in Table 11-2 be common to all cluster members, it does recommend that the data in the files be fully synchronized. Table 11-3 explains how to coordinate these files and suggests possible consequences of poor synchronization.

Some of the recommended files are created only on request and may not exist in all configurations. Note that a file may be absent on one node only if it is absent on all other nodes. As soon as any required file is created on one node, it must be created or commonly referenced on all remaining cluster members.

Table 11-2 System Files Recommended to Be Common

File	Description
VMS$AUDIT_SERVER.DAT	Contains information related to security auditing, such as enabled security-auditing events and the destination of the system security audit log file.
VMS$PASSWORD_HISTORY.DATA	Contains the system password history database. This file is maintained by the SET PASSWORD utility.
VMSMAIL_PROFILE.DATA	Contains the system mail database. This file is maintained by the Mail utility (MAIL). It holds mail profiles for all system users as well as a list of all mail forwarding addresses in use on the system.
VMS$PASSWORD_DICTIONARY.DATA	Contains the system password dictionary. The system password dictionary is a list of English words and phrases that cannot be used as account passwords.
VMS$PASSWORD_POLICY	Contains any site-specific password filters. This file is created and installed by the security administrator or system manager. (See Section 7.3.3.3 for details on password filters.)

11.2.3 Synchronizing Multiple Versions of Files

Using shared files is not the only way of achieving a single security domain. Some sites may have requirements for multiple copies of one or more of these system files on different nodes in a cluster. As long as the security information available to each node in the cluster is exactly the same, these sites operate in a single security domain.

Table 11-3 lists the files that require coordination, explains when to update these files, and suggests possible consequences of poor synchronization.

Table 11-3 Using Multiple Versions of Required Cluster Files

File	Coordination Required	Result of Poor Synchronization
VMS$AUDIT_SERVER.DAT	Update after any SET AUDIT command.	Possible partitioning of auditing domains
NETOBJECT.DAT	Update all versions after any NCP SET OBJECT or DEFINE OBJECT command.	Unexplained network login failures and unauthorized network access
NETPROXY.DAT NET$PROXY.DAT	Update all versions after any AUTHORIZE proxy command.	Unexplained network login failures and unauthorized network access
RIGHTSLIST.DAT	Update all versions after any change to any identifier or holder records.	Possible unauthorized system access and unauthorized access to protected objects
SYSALF.DAT	Update all versions after any SYSMAN ALF command.	Unexplained login failures and unauthorized system access
SYSUAF.DAT	Update all versions so the fields listed in Table 11-4 are synchronized for each user record.	Possible unexplained login failures and unauthorized system access.
SYSUAFALT.DAT	Update all versions after any change to any authorization records in this file.	Possible unexplained login failures and unauthorized system access
VMS$OBJECTS.DAT	Update all versions after any change to the security profile of a cluster-visible object or after new cluster-visible objects are created. (See Section 11.5 for details.)	Possible unauthorized access to protected objects
VMSMAIL_PROFILE.DATA	Update all versions after any changes to mail forwarding parameters.	Possible authorized disclosure of information
VMS$PASSWORD_HISTORY.DATA	Update all versions after any password change.	Possible violation of the system password policy
VMS$PASSWORD_DICTIONARY.DATA	Update all versions after any site-specific additions.	Possible violation of the system password policy
VMS$PASSWORD_POLICY	Install common version on all nodes.	Possible violation of the system password policy

11.3 Synchronizing Authorization Data

On a cluster, all elements of the user authorization data should exist in a common database. These authorization elements include the system user authorization files (SYSUAF.DAT and its backup SYSUAFALT.DAT), the rights database (RIGHTSLIST.DAT), the network authorization file (NETPROXY.DAT) and its object database file (NETOBJECTS.DAT), which are present on all OpenVMS systems, and optionally, the autologin file, SYSALF.DAT.

A secure cluster requires that the authorization data be synchronized across all nodes. If a site chooses to maintain multiple versions of these files, then you must synchronize the data. Each user should have the same UIC, group number, and set of identifiers defined on every node. Coordination of privileges and access rights is also critical. A shared disk is protected only as much as its least protected node. If you maintain separate authorization files on each node in the cluster, ensure that user privileges are common across all copies of the system user authorization file (SYSUAF.DAT). Table 11-4 lists the fields of SYSUAF.DAT that must be identical on each node.

Table 11-4 Fields in SYSUAF.DAT Requiring Synchronization

Internal Name	$SETUAI Item Code
UAF$R_DEF_CLASS	UAI$_DEF_CLASS
UAF$Q_DEF_PRIV	UAI$_DEF_PRIV
UAF$B_DIALUP_ACCESS_P	UAI$_DIALUP_ACCESS_P
UAF$B_DIALUP_ACCESS_S	UAI$_DIALUP_ACCESS_S
UAF$B_ENCRYPT	UAI$_ENCRYPT
UAF$B_ENCRYPT2	UAI$_ENCRYPT2
UAF$Q_EXPIRATION	UAI$_EXPIRATION
UAF$L_FLAGS	UAI$_FLAGS
UAF$B_LOCAL_ACCESS_P	UAI$_LOCAL_ACCESS_P
UAF$B_LOCAL_ACCESS_S	UAI$_LOCAL_ACCESS_S
UAF$B_NETWORK_ACCESS_P	UAI$_NETWORK_ACCESS_P
UAF$B_NETWORK_ACCESS_S	UAI$_NETWORK_ACCESS_S
UAF$B_PRIME_DAYS	UAI$_PRIMEDAYS
UAF$Q_PRIV	UAI$_PRIV
UAF$Q_PWD	UAI$_PWD
UAF$Q_PWD2	UAI$_PWD2
UAF$Q_PWD_DATE	UAI$_PWD_DATE
UAF$Q_PWD2_DATE	UAI$_PWD2_DATE
UAF$B_PWD_LENGTH	UAI$_PWD_LENGTH
UAF$Q_PWD_LIFETIME	UAI$_PWD_LIFETIME
UAF$B_REMOTE_ACCESS_P	UAI$_REMOTE_ACCESS_P
UAF$B_REMOTE_ACCESS_S	UAI$_REMOTE_ACCESS_S
UAF$R_MAX_CLASS	UAI$_MAX_CLASS
UAF$R_MIN_CLASS	UAI$_MIN_CLASS
UAF$W_SALT	UAI$_SALT
UAF$L_UIC	Not applicable

Use SYSMAN if you choose to create an autologin file and maintain the file in the common authorization database with your authorization files and rights database. On clustered systems, the autologin file must include the cluster node name as a prefix to the terminal name. For example, the terminal TTA0 on node WILLOW would be represented as WILLOW$TTA0. See Section 11.7 for an overview of SYSMAN.

11.4 Managing the Audit Log File

The audit server database VMS$AUDIT_SERVER.DAT contains information about events to be audited, the location of the audit log file, and information used to monitor its consumption of resources.

The audit log file resides in SYS$COMMON:[SYSMGR]. If you should decide to redirect the audit log off the system disk, it is important to redirect it uniformly across all nodes on the cluster. You use the command SET AUDIT/JOURNAL=SECURITY/DESTINATION=filename. Make sure that the file name you assign resolves to the same file throughout the cluster, not a file unique to each node. OpenVMS Cluster Systems describes the procedure in detail.

11.5 Protecting Objects

A single security domain is one in which each cluster member must make the same access control decision when presented with a particular user's access request for a particular object. The operating system provides this level of protection for files, queues, other cluster-visible objects: devices, disk and tape volumes, and resource domains. Table 11-5 summarizes the behavior of each object class and explains where each stores security profiles. See Chapter 5 for a description of each object class.

Table 11-5 Summary of Object Behavior in a Cluster

Class	Visibility in Cluster	Location of Profile
Capabilities	Visible only to local node.	Stored on local node.
Devices	Some can be visible clusterwide.	Profiles stored in VMS$OBJECTS.
Files	Visible clusterwide.	Stored in file header.
Global sections	Visible only to local node.	Stored on local node.
Logical name tables	Visible only to local node.	Stored on local node.
Queues	Visible clusterwide.	Stored in job-controller queue database (see Table 11-1).
Resource domains	Visible clusterwide.	Stored in VMS$OBJECTS.
Security class	Visible clusterwide.	Stored in VMS$OBJECTS.
Volumes	Can be visible clusterwide.	Stored on the volume.

11.6 Storing Profiles and Auditing Information

The audit server creates and maintains the security elements of clusterwide objects in a database called VMS$OBJECTS.DAT, located in SYS$COMMON:[SYSEXE]. You should ensure that the object database is present on each node in the cluster by specifying a file name that resolves to the same file through the cluster, not to a file that is unique to each node.

To reestablish the logical name after each system boot, define the logical in SYSECURITY.COM. The command procedure SYSECURITY.COM has to be defined before the audit server starts up.

The object database contains the following information:

• Audit and alarm settings for all objects, established through the DCL command SET AUDIT
• Template profiles for all security profiles, as described in Chapter 5
• Security profiles for all resource domain objects, all security class objects, and all cluster-visible devices (see Section 11.5)

This database is updated whenever characteristics are modified, and the information is distributed so that all nodes participating in the cluster share a common view of the objects.

Ordinarily, it is not possible to change security profiles or create protected objects when the object server is absent and cannot update the cluster database VMS$OBJECTS.DAT. However, you can modify the system parameter SECURITY_POLICY to allow security profile changes to protected objects on a local node (bit 4) or the creation of protected objects on a local node (bit 5).

11.7 Using the System Management Utility

The System Management utility (SYSMAN) is a facility supporting the cluster work of the security administrator. Through its centralized management of nodes and clusters, SYSMAN lets you perform system management tasks from your local node that the utility executes on all nodes in the target environment.

To use SYSMAN requires OPER privilege on the local node and authorization for the OPER privilege on any remote node. The utility does not require a password when you are operating within a cluster in your own account. The operating system audits any logical link connections or any operation in which the utility requires a password.

System managers using SYSMAN should be careful that logical names are set to the same name on each node.

11.8 Managing Cluster Membership

Clustered systems use a group number and a cluster password to allow multiple independent clustered systems to coexist on the same extended local area network (LAN) and to prevent accidental access to a cluster by unauthorized computers. The group number uniquely identifies each cluster system on a LAN. The cluster password serves as an additional check to ensure the integrity of individual clusters on the same LAN that accidentally use identical group numbers. The password also prevents an intruder who discovers the group number from joining the cluster.

The cluster group number and password (in encrypted form) are maintained in the cluster authorization file, SYS$COMMON:[SYSEXE]CLUSTER_AUTHORIZE.DAT. This file is created during installation of the operating system if you indicate that you want to set up a local area or mixed interconnect cluster. The installation procedure then prompts you for the cluster group number and password.

Under normal conditions, you need not alter records in the CLUSTER_AUTHORIZE.DAT file interactively. However, if you suspect a security breach, you may want to change the cluster password. In that case, you use SYSMAN to make the change. The file is accessible only to users with the SYSPRV privilege. Note that if you change either the group number or the password, you must reboot the entire cluster.

If your configuration has multiple system disks, each disk must have a copy of CLUSTER_AUTHORIZE.DAT. You must run SYSMAN to update all copies.

The following command sequence illustrates the use of SYSMAN to change the cluster password:

SYSMAN> SET CLUSTER_AUTHORIZATION/GROUP_NUMBER=65353
SYSMAN> SET ENVIRONMENT/CLUSTER/NODE21
SYSMAN> SET PROFILE /PRIVILEGE=SYSPRV
SYSMAN> CONFIGURATION SET CLUSTER_AUTHORIZATION/PASSWORD=HOOVER
%SYSMAN-I-CAFOLDGROUP, existing group will not be changed
%SYSMAN-I-GRPNOCHG, Group number not changed
%SYSMAN-I-CAFREBOOT, cluster authorization file updated
 The entire cluster should be rebooted.

The cluster environment provides such a rich resource-sharing model (which includes files and volumes, disk and tape devices, and batch and print queues) that it is usually unnecessary to directly access another cluster node through DECnet software. Nonetheless, there are situations where resources may not be uniformly shared across the cluster. This is particularly true in mixed interconnect or local area cluster configurations, where you may choose to limit cluster access to a satellite's disk or tape volumes. In such cases, users need to use the DCL command SET HOST or some form of network access to access a satellite's resources from other cluster members. See Section 12.3 for more information on network access through proxy logins.

Security in a network environment is even more sensitive than security in a single-system environment. Security is also harder to achieve because of operational complexities and the decentralization of control that commonly exist in networks. The larger the network, the more difficult the problem of establishing control and communication between security administrators of the numerous nodes.

There are limitations in the degree of security any networking site can expect to achieve due to limitations currently present in networking technology. Being sensitive to potential problems can help you avoid operations that could increase the security exposure in your network. This chapter helps you recognize these problem areas and adjust your operations accordingly.

This chapter assumes you are familiar with the information in the DECnet for OpenVMS Networking Manual for DECnet Phase IV or DECnet/OSI Network Management for DECnet Phase V. For information on the Authorize utility, refer to the OpenVMS System Management Utilities Reference Manual.

12.1 Managing Network Security

DECnet for OpenVMS regulates access to the network on various levels:

• Privileges for access to the network. To perform any kind of network activity, all network users must have TMPMBX and NETMBX privileges. Privileged users hold privileges in addition to TMPMBX and NETMBX.
• Access control. To connect to a DECnet node, a user needs explicit access information, a proxy account, an application account, or a default DECnet account. (See Section 12.2.)
• Routing initialization passwords for connecting local nodes to remote nodes over synchronous or asynchronous lines. (See Section 12.5.)

There are three critical requirements for achieving security in a network environment:

• Common security policy There must be a correspondence between the initiating process on the source machine and the process on the target machine that works on behalf of the initiating process (see Figure 12-1). This correspondence must be managed by the two reference monitors and must be consistent with the security policy intended on the target machine (which is ultimately responsible for protecting the object). See Chapter 2 for a description of the reference monitor.
• Shared access control information The authorization database on the target machine must have some access authorization, such as an account or a proxy, that corresponds to the initiating process on the source machine.
• Protected circuits, lines, terminals, and processors There must be a protected means of communication between the two reference monitors (source and target) so that correspondence between the local and remote subjects can be reliably established and authenticated.

Figure 12-1 The Reference Monitor in a Network

Security administrators can audit network activity by enabling specific event classes with the SET AUDIT command. Possible audits include:

• Use of NCP commands. Each NCP command line is audited along with its completion status.
• Use of privilege. In a network environment, much of this privilege use is related to the use of the OPER privilege in modifying the volatile network database.
• Initiation and termination of connections. On VAX systems running DECnet Phase IV, each network connection results in four audits:
  1. The source node, which initiates the connection, logs the first event message.
  2. The target node receiving the incoming initiation message logs the second event.
  3. The third event message is logged by whichever node terminates the connection.
  4. The last event message is logged by the node where the link is terminated.
  With an incoming network connection, the auditing message has a remote user name field that identifies who initiated the connection. With outgoing logical link connections, the remote logical link identifier is always 0.

  12.2 Hierarchy of Access Controls

  Whenever a DECnet node attempts to connect to a remote DECnet node, it sends access control information to the remote node. Access control information can come from a number of sources. The following list shows the hierarchy of access control from highest to lowest priority:

  1. The network user on the local node can explicitly supply access control information. If this is the case, the remote node uses the access control information. See Section 12.2.1 for information about explicit access control.
  2. The local node checks to see if outgoing proxy access is enabled for a local node or an application. If proxy is enabled, the local node sends the initiating user name in the connect request. If proxy is also enabled on the remote node, the DECnet software determines if the initiating user has proxy access. See Section 12.2.2 and Section 12.3 for information about proxy access control.
  3. When the remote node sees that no access control has been specified and that no proxy is applicable, it checks the configuration database. If the database contains an application user name, it uses that name. See Section 12.2.3 and Section 12.4 for information about default application accounts.
  4. If there is no default application user name in its configuration database, the remote node checks the configuration database for default nonprivileged DECnet user name information. If the information is there, the remote node uses the default nonprivileged DECnet user name. See Section 12.4 for information about the default DECnet account.

  Finally, if none of these sources supply the information, the connection fails.

  12.2.1 Using Explicit Access Control

  Users can execute a DCL or an NCP command on a remote node by supplying explicit access control information. The access control information contains a user name and password and provides access to a specific account on the remote system. To supply explicit access control information, you can use either a standard OpenVMS node specification or an NCP command:

  • In the OpenVMS node specification, the access control string consists of the user name for the remote account and the user's password enclosed within quotation marks:

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

    In the following, user Puterman uses an access control string to copy the file BIONEWS.MEM:

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

  • If you want to execute an NCP command on a remote node, you can do so by specifying a user name and password. In the following example, you can display all characteristics information about the application MAIL on the remote node TORONTO:

    NCP> TELL TORONTO USER A_JOHNSTON PASSWORD XZZOQ87 SHOW OBJECT-
    _NCP> MAIL CHARACTERISTICS
    

  12.2.2 Using Proxy Logins

  A proxy login enables a user logged in at a remote node to be logged in automatically to a specific account at the local node, without having to supply any access control information. Note that a proxy login is not the same as an interactive login. A proxy login means that specific network access operations can be executed, such as a copy operation. By contrast, an interactive login requires a user to supply a user name and password before the user can perform any interactive operations.

  ---

  Previous | Next | Contents | [Home] | [Comments] | [Ordering info] | [Help]

  ---

  
  

    6346P020.HTM
    OSSG Documentation
    22-NOV-1996 13:05:21.38
  

  Copyright © Digital Equipment Corporation 1996. All Rights Reserved.

  Legal