![[OpenVMS documentation]](../../images/openvms_doc_banner_top.gif)
|
![[Site home]](../../images/buttons/bn_site_home_off.gif)
![[Send comments]](../../images/buttons/bn_comments_off.gif)
![[Help with this site]](../../images/buttons/bn_site_help_off.gif)
![[How to order documentation]](../../images/buttons/bn_order_docs_off.gif)
![[OpenVMS site]](../../images/buttons/bn_openvms_off.gif)
![[Compaq site]](../../images/buttons/bn_compaq_off.gif)
|
| Updated: 11 December 1998 |
|
|
|
|
| Updated: 11 December 1998 |
OpenVMS Guide to System Security
| Previous | Contents | Index |
This chapter describes concerns for security administrators of clustered systems. Clustered systems refer to those systems using hardware and software that permits sharing of disks, resources, and a common operating system among various computers. Clusters of VAX processors are said to be joined in a VAXcluster environment, whereas clusters including both Alpha processors and VAX processors are said to be joined in a VMScluster environment. To properly secure your cluster, you should be familiar with the information in OpenVMS Cluster Systems.
OpenVMS Cluster Systems describes the tasks of the cluster manager. The cluster manager's job is the same as that of any system manager, but the cluster manager has to implement changes across many nodes. The security administrator for a cluster generally requires the same training and skills as a cluster manager, and at some cluster sites, the same person serves in the role of security administrator as well as cluster manager. At other sites, there may be one or more security administrators in addition to a cluster management team.
When a site separates the security administrator function from the
cluster management function, coordination, cooperation, and
communication between these functions becomes vital. As in previous
chapters, this chapter uses the title of security administrator to
refer to individuals who have the responsibility for system security,
regardless of what other responsibilities they hold.
11.1 Overview of Clusters
Clustered systems provide a uniform computing environment that is highly scalable, highly available, and secure. It is critical that there be a single set of authorized users and that these users be able to have processes executing on any cluster member.
To achieve a uniform computing environment, a cluster relies on the following components operating across all cluster members:
Within a cluster, authorization data for users and the security
profiles of objects must be consistent across all nodes so that each
cluster member makes the same access control decision when presented
with a particular user's access request for a particular object.
Section 11.2 and Section 11.3 describe how to achieve a single
security domain.
11.2 Building a Common Environment
Within a cluster, access control is mediated by individual nodes using a common set of authorization information. In the single security domain model, a process, acting on behalf of an authorized individual, requests access to a cluster-visible object, and a coordinating node determines the outcome by comparing its copy of the common authorization database with the security profile for the object being accessed. This model enforces security only when the authorization information and the object security profiles are consistent across all nodes in the cluster.
To achieve data consistency within the cluster, a site needs to:
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.
| 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. |
Although Compaq 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.
| 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.) |
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.
| 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 |
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.
| 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.
| 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. |
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:
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. |
| Previous | Next | Contents | Index |
|
|
![[OpenVMS documentation]](../../images/openvms_doc_banner_bottom.gif) |
|
Copyright © Compaq Computer Corporation 1998. All rights reserved. Legal |
6346PRO_026.HTML
|