Features and Concepts

Contents
vmx32besp
Contents
This section summarizes the features and components in
VM:Secure
and some of the concepts you must understand before you decide how to use or customize these components for your site.
Product Directory Database
The
VM:Secure
directory 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:Secure
directory entries are kept in individual files. One or more of these directory entry files are combined to form a
virtual machine definition
which specifies the configuration and characteristics for a virtual machine or VM user ID. There are two types of
virtual machine definition
:
  • Single configuration
    This type is formed from a USER directory entry, optionally combined with an included PROFILE directory entry.
  • Multiconfiguration
    This type is formed from an IDENTITY directory entry, optionally combined with an included PROFILE directory entry, and merged with all associated SUBCONFIG directory entries.
In the
VM:Secure
directory 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:Secure
directory 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.
For information about how the directory database is created, see VMXGNR Utility in Utility Reference.
Configuration Files
VM:Secure
uses configuration files to control the processing of many product - related functions. Each configuration file can include only specific records. The configuration files are:
  • AUTHORIZ CONFIG
    Controls who is authorized to issue
    VM:Secure
    commands.
  • DASD CONFIG
    Maintains information about DASD controlled by
    VM:Secure
    .
  • PRODUCT CONFIG
    Controls how
    VM:Secure
    operates.
  • SECURITY CONFIG
    Controls password processing.This file also controls how the Rules Facility operates.
Most configuration records in these files can be changed while
VM:Secure
is running, and their new values become effective as soon as you save the changes in the configuration file. This is referred to as
dynamic
reconfiguration.
Several configuration file records cannot be changed while
VM:Secure
is running.
For more information about these records, see Configuration Files and Records.
You can update these configuration files directly through an XEDIT interface controlled by
VM:Secure
.
For more information about each of the configuration files and their associated records, see Configuration File Reference in
Reference
.
If you use
VM:Secure
to 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:Secure
for SFS, and
VM:Secure
alone maintains it, based on the descriptions and enrollments you add to
VM:Secure
. If you edit this file directly, you will invalidate the
VM:Secure
functions for SFS management.
For more information about configuration for SFS, see Configuring the Product for SFS.
VMSECURE
MANAGERS File
The
VMSECURE
MANAGERS 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
VMSECURE
MANAGERS file and the records it uses, see MANAGERS File Reference.
VMSECURE
GLOBALS File
The
VMSECURE
GLOBALS file, which resides on the
VM:Secure
DRCT minidisk, contains the
VM:Secure
version 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
VMSECURE
GLOBALS file, see GLOBALS File Reference.
VMSECURE
POSIX File
The
VMSECURE
POSIX file, which resides on the
VM:Secure
DRCT minidisk, contains the POSIX group definitions. Use this file, instead of the USER DIRECT file, to define POSIX groups.
For more information about the
VMSECURE
POSIX file and other POSIX-related information, see POSIX Support.
DASD Management
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:Secure
uses 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.
Directory Management
When you create a new user ID, one or more directory entries are added to the
VM:Secure
directory database.
VM:Secure
creates 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
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.
Directory Profiles
In a z/VM system, you define each user with
virtual machine definitions
in 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 the
    VM:Secure
    DRCT 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 Administration
documentation.
Authorizations
Most
VM:Secure
command 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:Secure
functions, 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
system administrator
and
directory managers
. If you are using SFS, the SFS - related functions should be restricted to the user IDs you make
SFS administrators
and
SFS managers
.
System Administrator
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:Secure
system administrator by adding a GRANT record to the AUTHORIZ CONFIG file.
For information about user authorizations and granting user authorizations, see Authorizations. For more information about the GRANT record and how to use it, see GRANT Record in Configuration File Reference in
Reference
.
Directory Manager
VM:Secure
lets 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 Administrator
SFS administrators in
VM:Secure
perform three primary functions:
  • Identify to
    VM:Secure
    the 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 under
    VM:Secure
  • Enroll any user ID in any SFS file pools under
    VM:Secure
    control, 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:Secure
by adding a GRANT SFSADMIN record to the AUTHORIZ CONFIG file for that user ID.
For information about user authorizations and granting user authorizations, see Authorizations. For more about the GRANT record and how to use it, see GRANT Record in Configuration File Reference in
Reference
.
SFS Manager
SFS managers in
VM:Secure
are 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:Secure
system administrator is of no consequence.
The SFS administrator defines SFS managers through the SFS Managers Configuration Menu.
Auditing
VM:Secure
records audit information for most
VM:Secure
commands and directory changes.If you are using the Rules Facility,
VM:Secure
audits the following CP commands as well: AUTOLOG, COUPLE, LINK, LOGON, LOGON BY, SPOOL, STORE HOST, TAG, TRANSFER, and XAUTOLOG.
VM:Secure
also audits CP Diagnose X’A0’ subcode 4 and Diagnose X’88’ subcode 8.
VM:Secure
writes audit records to the
VMSECURE
AUDIT 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.
For more information about the AUDITEXT command, VMXSRA and VMXSRB report programs, and the SECURITY REPORTS user exit, see
Reference
.
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:Secure
perform 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:Secure
and 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:Secure
for SFS administration and want to use the DELETE and CHANGE commands. With the Servant Facility, potentially long - running commands can execute on a
VM:Secure
servant instead of tying up the
VM:Secure
service virtual machine.
The Servant Facility is either enabled or disabled on your system, and is used by
VM:Secure
whenever
VM:Secure
needs 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.
Rules 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
Rules Facility
.
Directory Encryption
Directory encryption is an optional feature of
VM:Secure
and is available only if you have the Rules Facility installed. It allows your site to encrypt your
VM:Secure
directory database at the time it is created with the VMXGNR utility.
With directory encryption, all information in the
VM:Secure
directory 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:Secure
commands 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
Reference
.
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:Secure
directory database.
VM:Secure
does 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:Secure
encrypts the password entered by the user, then compares the encrypted password with the password stored in the
VM:Secure
directory 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
Rules Facility
.
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:Secure
supports 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.
  • VM:Secure
    RULEs definitions on each member system are identical
    . You have exactly the same access to those resources controlled by rules, on every member in the complex.
In a Single System Image complex,
VM:Secure
operates as a set of servers, with one server virtual machine running on each member system. A
master
server 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
An
agent
server runs on each other member node to perform this subset of the functions of the
master
server:
  • Compiling the Object Directory and Rules tables
  • Responding to External Security Manager requests from CP
The
agent
also implements additional new functionality:
  • Responds to synchronization requests from the
    master
    product server
  • Converts to replace the
    master
    server if an outage situation occurs