Features and Concepts
This section summarizes the features and components in
VM:Secureand some of the concepts you must understand before you decide how to use or customize these components for your site.
Product Directory Database
VM:Securedirectory database consists of a set of files that reside on the CMS - formatted DRCT minidisk. These files contain directory source statements that are compatible with the CP directory statements. However, unlike the single card - image directory file format used in CP,
VM:Securedirectory entries are kept in individual files. One or more of these directory entry files are combined to form a
virtual machine definitionwhich specifies the configuration and characteristics for a virtual machine or VM user ID. There are two types of
virtual machine definition:
- Single configurationThis type is formed from a USER directory entry, optionally combined with an included PROFILE directory entry.
- MulticonfigurationThis type is formed from an IDENTITY directory entry, optionally combined with an included PROFILE directory entry, and merged with all associated SUBCONFIG directory entries.
VM:Securedirectory database, each USER, PROFILE, IDENTITY, or SUBCONFIG entry is contained in a separate CMS file. The entries are combined to form the definition for each user ID on the system. For USER and IDENTITY entries, the file name of an entry is the name of the user ID it defines. PROFILE entry files are named by the identifier on an INCLUDE statement used to reference the entry. SUBCONFIG entry files are named by the identifier on a BUILD statement used to reference the entry. The file type of each file is the name of the directory manager for that directory entry.
Another directory database minidisk, the BKUP minidisk, is allocated on a separate volume, and receives copies of the directory entry files whenever they are modified. The files on this disk serve as a backup and enable you to recover the current status of the
VM:Securedirectory database in the event the DRCT minidisk is lost.
A third directory database minidisk, the HOLD minidisk, holds directory entry files of user IDs that have been temporarily removed from the CP directory. In this way, the actual disk space allocated for a held user’s minidisks is retained in the system while the directory entry for the user ID is not. You can easily restore the user ID to its original state.
VM:Secureuses configuration files to control the processing of many product - related functions. Each configuration file can include only specific records. The configuration files are:
- AUTHORIZ CONFIGControls who is authorized to issueVM:Securecommands.
- DASD CONFIGMaintains information about DASD controlled byVM:Secure.
- PRODUCT CONFIGControls howVM:Secureoperates.
- SECURITY CONFIGControls password processing.This file also controls how the Rules Facility operates.
Most configuration records in these files can be changed while
VM:Secureis running, and their new values become effective as soon as you save the changes in the configuration file. This is referred to as
Several configuration file records cannot be changed while
For more information about these records, see Configuration Files and Records.
You can update these configuration files directly through an XEDIT interface controlled by
If you use
VM:Secureto manage SFS allocations, information about your SFS is stored in a configuration file that you do not edit directly. This file, SFS CONFIG, is created when you configure
VM:Securefor SFS, and
VM:Securealone maintains it, based on the descriptions and enrollments you add to
VM:Secure. If you edit this file directly, you will invalidate the
VM:Securefunctions for SFS management.
For more information about configuration for SFS, see Configuring the Product for SFS.
VMSECUREMANAGERS file defines existing VM user IDs as directory managers to whom you can delegate directory management tasks. Each directory manager can perform routine directory maintenance, minidisk management, and user ID management tasks for a group of user IDs. These tasks include creating and deactivating user IDs and creating and changing passwords for user IDs. Typically, as system administrator, you will manage several directory managers, and the directory managers will manage the users.
For more information about
VMSECUREMANAGERS file and the records it uses, see MANAGERS File Reference.
VMSECUREGLOBALS file, which resides on the
VM:SecureDRCT minidisk, contains the
VM:Secureversion of the GLOBALDEFS section in the CP source directory. Use this file, instead of the USER DIRECT file, to specify default settings that can apply to all users on the system.
For more information about the
VMSECUREGLOBALS file, see GLOBALS File Reference.
VMSECUREPOSIX file, which resides on the
VM:SecureDRCT minidisk, contains the POSIX group definitions. Use this file, instead of the USER DIRECT file, to define POSIX groups.
For more information about the
VMSECUREPOSIX file and other POSIX-related information, see POSIX Support.
Disk space allocation is controlled through SUBPOOL records in the DASD CONFIG file. SUBPOOL records associate certain allocation parameters with a name that is referenced during allocation. Subpools do not directly define the space to be allocated, but contain DASD extent definitions that the subpool can use.
The actual disk storage definition begins with a VOLUME record that specifies the disk’s volume label and its device type. Each contiguous block of disk space on a volume that is to be allocated for user minidisks must be defined with an EXTENT record that follows the corresponding VOLUME record. Exact definitions indicate the beginning and ending cylinder or block address and the names of the subpools from which allocations can be made. The extents cannot overlap. You can also specify extents to be used by CP.
At system startup,
VM:Secureuses the records in the DASD CONFIG file to construct a disk storage layout. Each user definition is examined, and a complete storage map, defined at the minidisk level, is created in virtual memory. No minidisk, except those specifically listed in the DASD CONFIG file to be ignored, is allowed to overlap an extent definition or another minidisk.
When you create a new user ID, one or more directory entries are added to the
VM:Securecreates these entries based on statements contained in a skeleton file and a directory profile, or an input file on an accessed minidisk.
Skeleton files make it easier to define directory entries with the same characteristics.
Skeleton files are prototype CP directory entries. Control statements in skeleton files specify the entry name and components of each virtual machine, among other things. They can also contain INCLUDE statements that effectively include the statements from a directory profile in the skeleton file.
You can use skeleton files as the basis for directory entries for new user IDs. In contrast to directory profiles, however, skeleton files are not merely referenced by directory entries; rather, they are copied into the new directory entries for user IDs you create by using skeleton files.
For more information about using skeleton files, see Skeleton Files.
In a z/VM system, you define each user with
virtual machine definitionsin the CP online directory. Control statements in the directory entries specify the user ID, password, and components of each user’s virtual machine.
Directory profiles contain sets of frequently used control statements. Instead of entering the same control statements repeatedly in many directory entries, you can create one directory profile that contains these commonly used control statements. You then add an INCLUDE statement to each directory entry that needs to use the control statements in that directory profile.
Directory profiles offer several advantages over repeating the same control statements in numerous directory entries:
- Easier to define user IDs with the same characteristics
- Saves space in the CP online directory and theVM:SecureDRCT disk
- Easier to maintain or change numerous directory entries dynamically and at the same time
For information about using directory profiles with
VM:Secure, see Directory Profiles. For more information about directory profiles in general, see the appropriate IBM
Planning and Administrationdocumentation.
VM:Securecommand and utility functions should be restricted for use by only system administrator and directory manager user IDs. Restricting their use means that only these user IDs can perform powerful
VM:Securefunctions, although all users and all processes on your VM system benefit from them.
Most user ID and minidisk management functions should be restricted to the user IDs you make
directory managers. If you are using SFS, the SFS - related functions should be restricted to the user IDs you make
As system administrator, you are responsible for designating other system administrators (although this is not recommended) and directory managers, and defining directory managers’ and users’ authorizations.
You can designate any existing VM user ID as a
VM:Securesystem administrator by adding a GRANT record to the AUTHORIZ CONFIG file.
VM:Securelets you define existing VM user IDs as directory managers to whom you can delegate directory management tasks. Each directory manager can perform routine directory maintenance, minidisk management, and user ID management tasks for a group of user IDs. Typically, as system administrator, you will be managing several directory managers, and the directory managers will manage the users.
SFS administrators in
VM:Secureperform three primary functions:
- Identify toVM:Securethe SFS file pools and user storage groups on your system that it will manage
- Designate existing directory managers as SFS managers, and specify which file pools, storage groups, and default allocations those managers can use when they allocate SFS space underVM:Secure
- Enroll any user ID in any SFS file pools underVM:Securecontrol, giving that user ID any amount of file space in any storage group
You can designate any existing VM user ID as an SFS administrator in
VM:Secureby adding a GRANT SFSADMIN record to the AUTHORIZ CONFIG file for that user ID.
SFS managers in
VM:Secureare any directory managers that an SFS administrator has designated to also be SFS managers. SFS Managers can add, or enroll, any user ID that they can manage in SFS.
Any VM user ID that is a directory manager can be made an SFS manager. To designate a user ID as an SFS manager, you must be an SFS administrator (authority SFSADMIN); your status as a
VM:Securesystem administrator is of no consequence.
The SFS administrator defines SFS managers through the SFS Managers Configuration Menu.
VM:Securerecords audit information for most
VM:Securecommands and directory changes.If you are using the Rules Facility,
VM:Secureaudits the following CP commands as well: AUTOLOG, COUPLE, LINK, LOGON, LOGON BY, SPOOL, STORE HOST, TAG, TRANSFER, and XAUTOLOG.
VM:Securealso audits CP Diagnose X’A0’ subcode 4 and Diagnose X’88’ subcode 8.
VM:Securewrites audit records to the
VMSECUREAUDIT file on the AUDT minidisk each time a user issues an audited command. The AUDIT user exit is called for each record. You can use it to select which audit records you want to be written to the AUDT minidisk.
When the AUDT minidisk fills, use the AUDITEXT command to move the audit records to your 191 minidisk, and reinitialize the AUDT minidisk. You can then use the information in the audit records as input to the VMXSRA and VMXSRB report programs. VMXSRA generates a report showing usage of all audited CP commands; VMXSRB generates a report of all audited system actions. To exclude certain types of audit records from the reports, you can use the SECURITY REPORTS user exit.
The Servant Facility
The Servant Facility is an optional feature of
VM:Secure. It is a set of special servant virtual machines that help
VM:Secureperform long-running minidisk and SFS management CMS tasks. With the Servant Facility, directory managers can perform minidisk management functions disconnected from their terminals. This means that they can submit minidisk management requests to
VM:Secureand use their user IDs for other work while
VM:Secure, through the Servant Facility servant virtual machines, processes these requests.
You must use the Servant Facility if you use
VM:Securefor SFS administration and want to use the DELETE and CHANGE commands. With the Servant Facility, potentially long - running commands can execute on a
VM:Secureservant instead of tying up the
VM:Secureservice virtual machine.
The Servant Facility is either enabled or disabled on your system, and is used by
VM:Secureneeds extra servant machines to complete long - running tasks in a timely fashion. No user intervention, either by you or by any operators, is required to use the Servant Facility if it is enabled.
For more information about the Servant Facility, see Servant Facility.
The Rules Facility is an optional feature of
VM:Secure. It provides a level of security above passwords, enabling you to control access to a variety of system resources, including sensitive data on minidisks and tapes. You can define three levels of security rules through the Rules Facility -- user, group, and system -- and you can define defaults for those functions for which there are no specific rules.
For example, through the Rules Facility, you can set up rules to:
- Control access to system resources by restricting use of CP commands such as AUTOLOG, COUPLE, LINK, LOGON, SPOOL, STORE HOST, TAG, TRANSFER, and XAUTOLOG
- Delegate minidisk management by letting users decide who needs to supply a password to link to a minidisk they own
- Control access to system facilities such as Diagnose codes X’88’, X’A0’, and X’D4’
For more information about the Rules Facility, see
Directory encryption is an optional feature of
VM:Secureand is available only if you have the Rules Facility installed. It allows your site to encrypt your
VM:Securedirectory database at the time it is created with the VMXGNR utility.
With directory encryption, all information in the
VM:Securedirectory database is maintained in encrypted form. This prevents someone who inappropriately gains access to the disk containing the directory database from recognizing passwords or any other information in a directory entry. Authorized use of
VM:Securecommands continues to provide clear - text display of directory contents.
For more information about generating an encrypted directory, see VMXGNR Utility in the section "Utility Reference" in
Password Encryption Facility
The Password Encryption Facility (PEF) is an optional feature of
VM:Secure, and is available only if you have the Rules Facility installed. It allows your site to encrypt logon and minidisk passwords.
With PEF, all passwords are automatically encrypted. Encrypted passwords are maintained in the CP object directory and in the
VM:Securedoes not support partial encryption, where some passwords are encrypted and other passwords are clear text.
When a user issues a command that requires password checking and PEF is active,
VM:Secureencrypts the password entered by the user, then compares the encrypted password with the password stored in the
VM:Securedirectory database or the CP object directory, as required.
PEF provides both forward encryption and reversible encryption for passwords. Forward encrypted passwords can never be decrypted. Reversible encrypted passwords allow you to back out of PEF and revert to clear text passwords
For more information about installing and using PEF, see
VM Single System Image
The VM Single System Image facility is a capability which enables multiple VM systems to be defined and managed as if they were a single VM system.
VM:Securesupports this facility by supplying the following environmental characteristics:
- The CP Object Directory on each member system is identical. A USER virtual machine definition is exactly the same, no matter which member system that user runs on.
- Directory Management Interfaces on each member system are identical. You enter product commands exactly the same way, no matter which member you run on. All authorizations to product commands and services are identical for an administrator, directory manager, or general user.
- . You have exactly the same access to those resources controlled by rules, on every member in the complex.VM:SecureRULEs definitions on each member system are identical
VM:Secureoperates as a set of servers, with one server virtual machine running on each member system. A
masterserver runs on one member to perform all the function of a non-SSI product server, including:
- Processing commands
- Updating Configuration, Source Directory Entries, and Rules files
- Compiling the Object Directory and Rules tables
- Responding to External Security Manager requests from CP
agentserver runs on each other member node to perform this subset of the functions of the
- Compiling the Object Directory and Rules tables
- Responding to External Security Manager requests from CP
agentalso implements additional new functionality:
- Responds to synchronization requests from themasterproduct server
- Converts to replace themasterserver if an outage situation occurs