IBM z/VM hypervisor
This chapter describes the security aspects of z/VM facilities. It also introduces how the z/VM hypervisor can provide security in its virtualization environment on IBM LinuxONE and how it can be improved with the installation of an external security manager (ESM), such as IBM Resource Access Control Facility (RACF).
Protecting information from unintended use is one key element of a secure IT environment. The following methods can be used to ensure privacy of information:
•Access control
•Encryption methods
Access control mechanisms determine who has the right to access particular information or data. The access control mechanisms then verify who accesses the information (authentication) and whether they have the right to access this information (authorization).
Cases exist in which proper access control cannot be ensured in all situations, especially if data is stored on movable media and also when data is transferred through a network that might not be protected. It is not possible to ensure that no unintended access to data occurs while it is stored or transferred through a network. The only way to protect such information is by using encryption methods.
This chapter includes the following topics:
3.1 Virtualization
Organizations today are challenged to deliver improved information services to the business within severely constrained budgets. Many organizations are considering cloud computing models to gain benefits, including reduced cost and a shift in cost profile from capital to operating expense. Other benefits, such as scalability, improved flexibility and agility, and more efficient utilization of human and technology resources are also attractive.
Virtualization is the key for cloud as it creates the infrastructure of resources that are used by Cloud Computing. By using a virtual infrastructure, you can create a cloud by pooling virtual resources, orchestrating them by using management and automation software, and creating a self-service portal for users.
Virtualization is technology that allows you to create multiple simulated environments or dedicated resources from a single, physical hardware system. An operating system (called a hypervisor) connects directly to that hardware and allows you to split one system into separate, distinct, and secure environments that are known as virtual machines (VMs). These VMs rely on the hypervisor’s ability to separate the machine’s resources from the hardware and distribute them.
From the perspective of the enterprise, virtualization developed into a significant strategy for organizations that are facing rising costs, and do not want to affect service levels. The increasing need for agility in market response is also pushing more to implement virtualization, with more production VM images being deployed every day and development and test images deployed in minutes.
Virtualization provides a secure environment with isolation and sharing resources that allows a single platform to work as though multiple hardware environments were used. Because of the global economy, customers are driven by the business marketplace, and that pushes organizations to continue searching for higher efficiencies and better usage of IT resources.
Key growing cloud security concerns include the following examples:
•Securing highly virtualized environments from targeted threats and attacks
•Enabling secure user collaboration and protecting the data (isolation and sharing)
•Provisioning and de-provisioning (users and technical components) rapidly
•Losing direct control of security compliance and privacy parameters
3.1.1 Virtualization benefits
Virtualization provides the following benefits:
•Consolidation to reduce hardware costs
Virtualization enables clients to access and manage resources efficiently to reduce operations and systems management costs while maintaining needed capacity. It also enables clients to have a single-server function as multiple virtual servers.
•Optimization of workloads
Virtualization enables clients to respond dynamically to the application needs of its users. Virtualization also can increase the use of resources by enabling dynamic sharing of resource pools.
•IT flexibility and responsiveness
Virtualization enables clients to have a single, consolidated view of, and easy access to, all available resources in the network, regardless of location. It also enables clients to reduce the management of their environment by providing emulation for compatibility, improved interoperability, and transparent change windows.
By adding any of these virtualization technologies to your environment, you create an on-demand, secure, and flexible infrastructure that is prepared to handle workload changes in your environment. IBM virtualization is the answer for the Cloud because it perfectly adheres to the hardware server and uses the LinuxONE functionalities with efficiency, high throughput, and security that is inherent of this platform.
3.1.2 Hardware virtualization
The following facilities are available in LinuxONE servers and are used to divide the hardware into LPARs. They are classified as type 1 hypervisors, are run directly on the hardware, and are known as “native” or “bare metal”:
•IBM PR/SM™ is the facility on LinuxONE servers that provides another layer of virtualization. It is a hypervisor that is classified as type 1 and allows multiple LPARs to share physical resources, such as processors, memory, channel paths, and DASDs.
•Dynamic Partition Manager (DPM) is a new administrative mode that was introduced to LinuxONE servers. A system can be configured in DPM mode or PR/SM mode. The mode is enabled before system power-on reset (POR).
DPM provides the following advantages:
 – Fast
Much faster than managing with HCD and HCM (from hours to minutes).
 – Easy
Intuitive user interface. No need for multiple administrators with different skills or tools.
 – Powerful
The same efficient PR/SM hardware virtualization, without the complexity. It supports dynamic configuration changes with just a few mouse clicks. It provides a foundation for “bare metal” cloud.
3.2 z/VM hypervisor and LinuxONE servers
z/VM is the mature virtualization solution of IBM. It is reliable and flexible, and shares the resources to support thousand of guest servers with a high performance. As a hypervisor operating system, its security does not differ from the security of any other operating system on a server. However, the virtual infrastructure relies on the security of the hypervisor, so protecting the z/VM hypervisor often prevents attempts to breach the security of the operating system and compromises to the integrity of the operating system and data.
The merger of z/VM and Linux on LinuxONE is perfect because z/VM can have hundreds of Linux servers that are running harmoniously while z/VM manages all of the resources of the LPAR with the benefit of improved price performance as workloads grow.
A fundamental strength of z/VM is the ability for VMs to share system resources with high levels of resource usage. z/VM V7.1 provides even greater levels of extreme scalability, security, and efficiency to create opportunities for cost savings, while providing a robust foundation for cognitive computing on the LinuxONE platform.
When multiple Linux servers run on LinuxONE, each Linux system includes dedicated access to a defined portion of the LinuxONE machine as provided by the hypervisor by using a technique that is known as timesharing. Each Linux instance runs in its own VM whose characteristics (for example, memory size and number of CPUs) define the hardware that Linux sees. The allocation and tuning controls in z/VM specify how real hardware resources are allocated to the VM.
Although each guest (a Linux server) can have its own security configuration and faces its own threats, it is essential to protect the hypervisor as an equally important part of an overall end-to-end security policy because important activities, such as creating, changing, and removing VMs are performed at the hypervisor level. Protecting the guests and not the hypervisor is similar to locking all of the windows of your home and then leaving the front door open.
Performing z/VM maintenance is part of the system administrator role. It is important to apply service to your z/VM system to ensure that the latest security measures are in place; therefore, installing the corrections when they are released decreases the time frame that the vulnerability can be used.
In addition to operating system setup and customization for security, monitoring the hypervisor for signs of compromise helps you promptly respond to a threat. Use monitoring tools to help monitor the hypervisor and review the hypervisor logs for suspicious activities, both of which make the work of the hypervisor system administrator easier.
In addition to operating system setup and customization for security, monitoring the hypervisor for signs of compromise helps you promptly respond to a threat. Use monitoring tools to help monitor the hypervisor and review the hypervisor logs for suspicious activities, both of which make the work of the hypervisor system administrator easier.
 
Note: z/VM supports more VMs in a single footprint with more excellent service levels than any other solution. It also allows a user to scale up the system capacity without requiring more support personnel.
 
3.2.1 z/VM 7.1 overview
z/VM V7.1 supports IBM LinuxONE servers and Red Hat, SUSE, and Ubuntu Linux distributions. Support for simultaneous multithreading (SMT) technology extends per-processor, core capacity growth beyond single-thread performance for Linux guests that are running on an IBM Integrated Facility for Linux (IFL) specialty engine on IBM LinuxONE servers.
Its multithreading technology support provides more price and performance benefits over previous hardware generations. It also can meet workload requirements transparently. Improvements that are made in the areas of reliability, availability, and serviceability allow low-end devices, such as IBM Storwize® V7000, V840, and V9000, to be attached to a z/VM host, which removes the need for an IBM SAN Volume Controller.
z/VM V7.1 is a supported environment that uses IBM Dynamic Partition Manager for Linux-only systems. This configuration simplifies system administration tasks for a more positive experience. Also, the use of IBM Wave with z/VM can greatly simplify the task of administering a z/VM environment.
By using z/VM as a hypervisor for Linux workloads, you can extend the business value of IBM LinuxONE technology across the enterprise by integrating applications and data, while providing exceptional levels of availability, scalability, security, and operational ease.
Integration of z/VM SSI for continuous operation
z/VM single system image (SSI) is included in the base of z/VM V7.1 at no extra cost. Integrating and making SSI available at no charge is intended to help more clients reduce or shorten planned outages of their Linux workloads as they adopt the z/VM Continuous Delivery model for their z/VM systems. SSI includes live guest relocation and single system maintenance to give clients a mechanism to host Linux virtual server images without suffering interruptions as they apply updates to their z/VM systems.
 
Note: For more information about z/VM 7.1 and its functionalities, see this website.
3.2.2 Single System Image overview
The architecture of Linux solutions on IBM LinuxONE changed dramatically when z/VM Single System Image (SSI) is used with live guest relocation (LGR).
An SSI cluster is a multi-system environment on which the z/VM systems can be managed as a single resource pool and guests can be moved from one system to another while they are running. Each SSI member is a z/VM logical partition (LPAR) connected through channel to channel (CTC) connections, and the z/VM SSI cluster consists of up to four z/VM systems in an Inter-System Facility for Communications (ISFC) collection. CTC connections are physical connections and because the channels are isolated from the outside world, the traffic does not need to be encrypted.
Each z/VM system is a member of the SSI cluster and is self-managed by the z/VM Control Program (CP). All members can access shared DASD volumes, and the same Ethernet LAN segments and storage area networks (SANs).
 
Note: Starting with z/VM 7.1, SSI is included in the base hypervisor at no extra cost. Integrating and making SSI available at no charge helps more clients reduce or shorten planned outages of their Linux workloads as they adopt the Live Guest Relocation (LGR) for their z/VM systems.
Live guest relocation
With the IBM z/VM SSI, a running Linux on IBM LinuxONE can be relocated from one member z/VM system to any other, a process known as LGR. LGR occurs without disruption to the business and provides application continuity across planned z/VM and hardware outages and flexible workload balancing that allows work to be moved to available system resources.
A running virtual server might need to be relocated for one of the following reasons:
•Increased flexibility for planned outages
•Maintenance of hardware or software
•Fixing performance problems
•Management and balancing of workloads
Relocating virtual servers can be useful for load balancing and for moving workload off a physical server or member system that requires maintenance. After maintenance is applied to a member, guests can be relocated back to that member, which allows you to maintain z/VM and keep your Linux on IBM LinuxONE virtual servers available.
Note: Currently, Linux server running in z/VM is the only guest environment that is supported for relocation.
For more information about SSI and LGR, see the following resources:
•z/VM CP Planning and Administration version 7 release 1, SC24-6271
•An Introduction to z/VM Single System Image (SSI) and Live Guest Relocation (LGR), SG24-8006
•Using z/VM 6.2 Single System Image (SSI) and Live Guest Relocation (LGR), SG24-8039
•Chapter 7 of The Virtualization Cookbook for IBM z Systems Volume 1: IBM z/VM 6.3, SG24-8147.
Changes for SSI in the USER directory
The z/VM user directory (or user registry) describes the configura­tion and operating characteristics of each virtual machine that can be created by CP. A z/VM user directory exists in two forms: a source form that consists of one or more CMS files, and an object form (which is created from the source) on a CP-formatted disk.
The source form of the user directory consists of directory statements that define the CP volume on which the object directory is created and the characteristics of each virtual machine that runs on z/VM system.
This section provides an overview of the following definitions in the z/VM directory for guests with single configuration and multiple configurations (see Figure 3-1 on page 31):
•Single-configuration VM
A single-configuration VM definition consists of a user entry and any included profile entry. For example, you can specify a single-configuration virtual machine as EDI and log on to a z/VM system as EDI. In an SSI cluster, the VM can be logged on to only one SSI member at a time. Your Linux guests are always defined as single users.
•Multi-configuration VM
A multi-configuration VM definition consists of an identity entry and all associated subconfiguration entries (SUBCONFIG in BUILD ON z/VM Directory Manager (IBM DirMaint™) statement). In an SSI environment, this VM definition allows multiple instances, which enables the user ID to be logged on concurrently to multiple members of the SSI cluster. Each of these VM instances can have a different configuration as minidisks in each LPAR member, and so on.
Figure 3-1 User definitions as a User or Identity
USERs are relocatable and can access the same resources no matter to which par they go. An IDENTITY is restricted to a single cluster member and might access private resources of each z/VM member.
 
Note: A z/VM SSI cluster uses a single source directory to define VMs on the system. However, separate object directories are built on each member node of the cluster. As a result, care must be exercised when changing VMs on the system so that a new object directory is compiled on each member of the cluster at the same time.
3.2.3 Security settings in an SSI cluster
The following preferred practices can be used to make your SSI cluster more secure and compliant with security rules:
•A Single Configuration VM can log on to only one member of the cluster.
•A Multi-Configuration Virtual Machine can have a different definition on each system.
•A user ID’s privilege classes and passwords are the same on every system.
A common source directory definition is available.
•The cluster maintains a single security context for the entire system.
An ESM extends these capabilities, even in stand-alone systems.
•Consider the use of Relocation Domains.
Relocation Domains can be built so that guests can be constrained to certain cluster members. It is a way of building security zones into the SSI by constraining data flow (where the data is the server).
A z/VM system is secured by using the security features of the LinuxONE hardware by maintaining compliance to security policy within operating practices. The system administrator must lead the way in following security standards and guidelines.
When the RACF feature for z/VM is installed, it can be configured to control functions normally being checked in the directory for authorization. RACF can control the password field, minidisk access, spool files, and commands privileges.
A preferred practice to extend the z/VM environment is installing an external security manager (ESM), such as IBM RACF for z/VM or other ESM product to maximize your security.
3.2.4 Controlling the System Operator
The System Operator is a highly privileged VM that runs under z/VM. It includes all CP defined privilege classes (and access to every command), and it has special authorities over the hypervisor. It also receives informational and error messages from the components of z/VM as they occur. This user ID (most commonly OPERATOR) should be given special protections, which are described in this section.
Controlled area
Run the system operator in a physically controlled environment; for example, in a machine room or in an operator's work area. Provide proper access control through badges for authorized personnel entry only.
Automation
Set up an automation environment so that the operator close console files daily so that operator logs are ready for archiving processes. By using system user IDs, set the observer as TCPIP, IBM DirMaint on the operator user ID.
Log on by definition
z/VM can define logon to a system by privileged user IDs, such as Operator, Maint, and Maint710.
RACF definition
With RACF, define the operator user ID as protected and enable surrogate logon processing by defining the appropriate RACF profile. Give access to surrogate profiles only to operating staff and perhaps system programmers.
 
Note: With RACF installed, set up an observer for operator user ID (by using Performance Toolkit for z/VM) to get an option of scrolling through the events that occurred in the past. If you do not set up this configuration, all RACF messages like ICH408I are directed to operator.
Because the operator’s console is spooled, you must close the operator console file and scroll through to see the history of system events to check the most recent messages. Consider the use of a tool that helps you manage the console log of the operator daily. The archiving of console logs can then be done by z/VM when you sent the system consoles to a repository user ID or by transferring it to other systems.
3.2.5 System Configuration file
The System Configuration file is one of the most important files of z/VM. It contains operating characteristics, such as the layout of the system residence disk, real storage, and I/O devices configuration and the description of other resources that are available to the system.
The system configuration file is on a partition of a volume that is called minidisk and it is allocated as PARM. This minidisk is under user ID PMAINT, and it is address is CF0. The file is called SYSTEM CONFIG by default, although you can change the name in your installation. The file is read at IPL time by the CP program that uses the statements that are contained in the file to configure the system.
 
Note: As a best practice, always run a CPSYNTAX check after modifying SYSTEM CONFIG to check whether errors exist on this file.
The statements that are contained in the configuration file that are relevant to security are summarized next.
DEFINE COMMAND
Use the DEFINE COMMAND or CMD statement to define a new CP command or a new version of a CP command on the system during initialization.
DEFINE LAN
Use the DEFINE LAN statement to create a guest LAN that can be shared among virtual machines on the same VM system. Each guest LAN segment is identified by a unique combination of owner ID and LAN name. A VM user can create a simulated network interface card (NIC) and connect it to this LAN segment.
DEFINE VSWITCH
Use the DEFINE VSWITCH statement to create a CP system-owned switch (a virtual switch) to which VMs can connect. Each switch is identified by a switchname. A z/VM user can create a simulated QDIO NIC and connect it to this switch with the NICDEF directory statement. Under the DEFINE VSWITCH statement, the VLAN parameter is important if you want to isolate guests subnets based on VLAN IDs.
DISABLE COMMAND
Use the DISABLE COMMAND or CMD statement to prevent CP from processing requests for the specified CP command during and after initialization.
ENABLE/DISABLE DIAGNOSE
Use the ENABLE/DISABLE DIAGNOSE statement to permit/prevent CP from processing requests for one or more locally developed DIAGNOSE codes during and after initialization.
ENFORCE_BY_VOLid
Use the ENFORCE_BY_VOLid configuration statement to enforce attachment of DASD devices by their VOLIDs on the ATTACH command.
FEATURES
Use the FEATURES statement to set certain attributes of the system at system initialization.
JOURNALING
Use the JOURNALING statement to tell CP whether to include the journaling facility, whether to enable the system being initialized to set and query the journaling facility, and what to do if someone tries to log on to the system or link to a disk without a valid password.
 
 
Note: Journaling is not a sufficient replacement for ESM auditing, which is done by RACF.
MODIFY COMMAND
Use the MODIFY COMMAND or CMD statement to redefine an existing CP command on the system during initialization.
MODIFY LAN
Use the MODIFY LAN statement to modify the attributes of a guest LAN during initialization.
MODIFY VSWITCH
Use the MODIFY VSWITCH statement to modify the attributes of a virtual switch.
PRIV_CLASSES
Use the PRIV_CLASSES statement to change the privilege classes authorizing the following
CP functions:
•Logging on as the primary system operator
•Intensive error recording
•Using the read function of the CP IOCP utility
•Using the write function of the CP IOCP utility
•Specifying the default user class
MODIFY PRIV_CLASSES
Use MODIFY PRIV_CLASSES to change the privilege classes that are authorizing the following CP functions:
•Logging on as the primary system operator
•Intensive error recording
•Using the read function of the CP IOCP utility
•Using the write function of the CP IOCP utility
•Specifying the default user class.
SYSTEM_USERIDS
Use the SYSTEM_USERIDS statement to specify user IDs that perform special functions during and after IPL. These functions include accumulating accounting records, system dump files, EREP records, and symptom records, and specifying the primary system operator’s user ID and disconnect status.
USER_DEFAULTS
Use the USER_DEFAULTS statement to define default attributes and permissions for all users on the system.
Password suppression
Password suppression prevents any password from being visible on a user’s screen. Suppression of visibility of passwords is mandatory to be compliant with your corporate security policies. To enable password suppression, place the following statement in the SYSTEM CONFIG file:
FEATURES PASSWORDS_ON_CMDS AUTOLOG NO LINK NO LOGON NO
Preventing users of T-disks and minidisks from seeing residual data
You must ensure that each time the system assigns T-disk space, it clears the space of all residual data. To ensure that this process occurs, place the following statement in the SYSTEM
CONFIG file:
FEATURES ENABLE CLEAR_TDISK
Before the minidisk is released, it must be formatted to clear it of any residual data.
 
Note: For more information about the syntax and usage for the system configuration file, see z/VM CP Planning and Administration, SC24-6271.
3.2.6 Addressing password security
The passwords in a standard z/VM system are default passwords that are defined by the installation process. Before moving your system into production, change those passwords immediately to be compliant with your corporate security policies.
It might be mandatory based on your company policy, industry, or government regulations to change the following two types of passwords in the USER DIRECT file:
•userid: The password that is required to logo n.
•minidisk: The minidisk password, which gives access to read, write, and multiple.
Changing that password can be done manually by using XEDIT, which is the z/VM text editor, or by using a macro to automate the process. Alternatively, a directory management product, such as IBM DirMaint, can be used.
Because manually changing the password is a tedious and error-prone process, make a backup copy of the USER DIRECT file only after the default passwords are changed.
Special passwords
The following special passwords in the User Direct file have specific functions:
NOLOG When the user ID is set with NOLOG, it cannot be used to log in to a z/VM system until you set another password. As a preferred practice, set all unused VMs to NOLOG.
AUTOONLY The user ID starts running only when you issue the xautolog or autolog commands. You cannot issue logon or logoff for this user ID.
LBYONLY This user ID can be logged on only by issuing the logon by command. You cannot log on this user ID with the logon command.
RACF control of passwords supersedes any password definitions in the CP User Directory, except the special passwords listed here. For more information, see “Password and password phrases rules” on page 115.
3.2.7 Implementing CP LOGONBY
The CP LOGONBY directory statement designates up to eight VMs to have access to another VM user ID. This function was originally a DirMaint implementation and was added to VM several releases ago. The CP LOGON BY command allows authorized VMs to log on to a shared VM by using their own password. This command is useful when several VM system supports must share the MAINT user ID, but only one person can be logged on at a time.
To fully understand this command, you must become familiar with the following terms:
•Shared user: A user ID that can be logged on to by a different user.
•Surrogate user: A person logging on to the shared user ID.
•Direct logon: A traditional logon, in which you log on to your own user ID.
•Shared logon: A logon in which a surrogate user uses the BY option of the LOGON command to log on to a different user ID.
The implementation of CP LOGONBY can be done updating the user directory of the user that is intended to be used as the shared user with the LOGONBY entry. In Example 3-1 on page 36, user MAINT is defined to be shared and user EDI is defined as one of its surrogate users.
Example 3-1 User directory of a shared user ID
USER OP1 XXXXXXXX 64M 96M BG
INCLUDE IBMDFLT
IPL CMS PARM AUTOCR
LOGONBY EDI KLAUS KAREN MAC
Now, the user EDI can use their password to log on to the OP1 shared ID, as shown in Example 3-2.
Example 3-2 Logon using LOGONBY
L OP1 BY EDI
ENTER PASSWORD (IT WILL NOT APPEAR WHEN TYPED):
z/VM Version 7 Release 1.0, Service Level 1801 (64-bit),
built on IBM Virtualization Technology
There is no logmsg data
FILES: 0001 RDR, NO PRT, NO PUN
LOGON AT 09:46:46 EDT WEDNESDAY 06/12/19
z/VM CMS 29 002 01/21/19
It is possible to define up to eight users as surrogates of a shared user by using CP LOGONBY. This task can be done adding the users in the same LOGONBY statement of the shared user ID. Example 3-2 is an example of user MAINT being defined as surrogate of OP1.
The way the directory is defined in our examples makes it possible for user ID OP1 to be logged on by using its directory password. This configuration affects the accountability of a shared user ID because any person that knows the shared user ID password can log on directly to it.
To avoid this situation, use the keyword LBYONLY on the shared user ID password. It is not possible to log on the shared user ID by using the directory password. In fact, if a logon on the shared user ID is attempted, CP returns an error message and permits only to log on by that user ID, as shown in Example 3-3.
Example 3-3 Using LBYONLY statement to avoid direct logon to the shared ID
Shared user directory with the LBYONLY statement:
USER OP1 LBYONLY 64M 96M G
INCLUDE IBMDFLT
IPL CMS PARM AUTOCR
LOGONBY EDI WILLIANR
 
a) Tentative directly log on to OP1:
L OP1
HCPLGA050E LOGON unsuccessful--incorrect userid and/or password
b) Log on op1 by using the surrogate user ID:
L OP1 BY EDI
ENTER PASSWORD (IT WILL NOT APPEAR WHEN TYPED):
z/VM Version 7 Release 1.0, Service Level 1801 (64-bit),
built on IBM Virtualization Technology
There is no logmsg data
FILES: 0001 RDR, NO PRT, NO PUN
LOGON AT 09:46:46 EDT WEDNESDAY 06/12/19
z/VM CMS 29 002 01/21/19
This command can be extended by using the SURROGAT class in RACF for z/VM. For more information, see 4.3 “RACF management processes” on page 88.
3.2.8 Role-based access controls and CP privilege classes
In the z/VM system of privilege, a user either can have no privileges or can be assigned to one or more privilege classes. Each privilege class represents a subset of Control Program commands that the system permits the user to enter. Each privilege class, sometimes called CP privilege class, is defined around a particular job or set of tasks, which creates an area outside of which the user cannot go. It is common for a user to be assigned to more than one CP privilege class. Users cannot enter commands in privilege classes to which they are not assigned.
 
Note: Any user, except those users with NO PRIVILEGE or CP privilege class G, is considered part of the configuration but is not necessarily considered trusted.
It is also possible to create privilege classes that meet the enterprise security policy according to the roles that are described in it, as described in .
The following CP privilege classes are available:
Privilege class A The primary system operator. The system operator is among the most powerful and privileged of all z/VM users. The system operator is responsible for the system’s availability and its resources. The system operator also controls accounting, broadcasts messages, and sets performance parameters.
Privilege class B The system resource operator. The system resource operator controls the allocation and de-allocation of real resources, such as memory, printers, and DASD. The system resource operator does not control any resource that is already controlled by the system operator or the spooling operator.
Privilege class C System programmer. The system programmer updates the functions of the z/VM system and can change real storage in the real machine.
Privilege class D Spooling operator. The spooling operator controls spool files and real unit record devices, such as punches, readers, and printers.
Privilege class E System analyst. The system analyst has access to real storage and examines dumps to make sure that the system is performing as efficiently and correctly as possible.
Privilege class F IBM service representative. The representative of IBM who diagnoses and solves problems by examining and accessing real input and output devices and the data they handle.
Privilege class G CMS general user. This is the most prevalent and innocuous of the CP privilege classes. The commands that privilege class G users can enter affect only their own VMs.
Privilege classes A, B, C, D, E, and F should be granted to only human users and VM workloads after careful consideration regarding the scope of responsibility. For example, users with privilege class B or C can modify an installation’s system of CP privilege. Users with privilege class C can enter the cp store host command that alters real storage. Privilege class G users have the power to modify only their own VMs; they have little security relevance and cannot violate the security policies of the system.
In the CP, each level of privilege is discrete and not predicated on others. Furthermore, each privilege class has a subset of commands and they are related to one or more function types (subsets of users).
3.3 Device management
The following methods can be used to define I/O devices to the CP during IPL:
•Enable the CP dynamically sense devices.
•Use RDEV statements or EDEV statements in the system configuration file.
•Use RDEVICE macroinstructions in the HCPRIO ASSEMBLE file.
•Use the Hardware Configuration Manager (HCM) and Hardware Configuration Definition (HCD) or Dynamic Partition Manager (DPM) to define the devices.
Typically, CP senses the devices. Only devices that require more definition have an RDEVICE or an EDEVICE statement in the system configuration file.
 
Note: For more information about defining real devices, see Chapter 5, “Defining I/O devices”, in CP Planning and Administration, SC24-6271.
The capabilities support of real devices is done by CP on behalf of the virtual guests, which means to the virtual guests the device is transparent in use without having access to the physical device. CP provides the system services for the device, including error recovery for guest DIAGNOSE I/O requests and a full command set for the device. Devices can be dedicated to just one guest or shared among multiple guests (which is done for DASD).
If a device supports dedicated-only use by a single guest, this device must be logically attached to a single guest at any one time. The guest must be fully capable of running with the device. CP does not supply DIAGNOSE I/O services to the guest.
3.4 Securing the data
The protection and securing of an organization’s information is considered part of the foundation for business success. Ensuring strong security protection of your data is mandatory and should be deployed with a careful plan and overall understanding about the security and business requirements that your organization needs.
 
Note: As a starting point for defining your security policies, a smart decision is to begin with a closed security police and grant access and privileges as the business requires.
3.4.1 Securing your minidisks
The z/VM system is designed to permit access to the minidisks when you provide the correct link password that is defined on the z/VM directory. Another method is to include the link in your user direct definition. Because this environment is a controlled environment, it sounds like a secure approach, but only with an appropriate external security manager (ESM) to make your configuration resilient and less prone to error.
 
Note: As a best practice, change all the default passwords in the USER DIRECT file to avoid unauthorized access on the production system.
3.4.2 Encrypting z/VM page volumes
Encrypted Paging improves z/VM® system security by using IBM LinuxONE hardware to encrypt guest page data. Ciphering occurs as data moves from active memory onto a paging volume that is owned by CP, such as ECKD and SCSI devices. This configuration makes customer data defensible from an attack and from a breach of volumes, even in cases where a system administrator has unintended access to those volumes.
Encryption is limited to guest pages and virtual-disk-in-storage (VDISK) pages that are written by the CP paging subsystem to paging extents. This includes pages on an NSS/DCSS that was loaded.
The following types of pages (also written by the CP paging subsystem) are not encrypted:
•Spool files
•Directory pages
•Minidisk data to a mapped minidisk pool (established via the MAPMDISK interface)
•Minidisk cache pages
•CP page tables (PGMBKs)
 
Note: Encrypted Paging requires that the TRNG facility of CPACF of the IBM LinuxONE is enabled for the system.
Use the CP QUERY CRYPTO command to verify whether CPACF is enabled by issuing the command as shown in Example 3-4. It shows the status of the cryptographic hardware and the AP (AdjunctProcessor) of the Crypto-Express adapter.
Example 3-4 Query crypto to check whether it is enabled
Q CRYPTO
Crypto Adjunct Processor Instructions are installed
Ready; T=0.01/0.01 12:16:29
 
Note: Encrypted Paging is available starting with LinuxONE RockHopperII hardware and it is not supported on earlier machines.
Enabling z/VM encrypted paging
The following CP commands are available to query or set the encryption level:
•SET ENCRYPT
Sets dynamically enabled z/VM encrypted paging, as shown in Example 3-5 on page 40.
Example 3-5 Setting encrypt paging on or off
set encrypt paging on
Encrypt Paging set on to algorithm AES256
Encrypt Paging Settings:
Currently: On AES256
At IPL: Off
Ready; T=0.01/0.01 12:56:22
 
set encrypt paging off
Encrypt Paging set off
Encrypt Paging Settings:
Currently: Off
At IPL: Off
Ready; T=0.01/0.01 13:00:39
•QUERY ENCRYPT
z/VM encrypted paging status can be queried, as shown in Example 3-6.
Example 3-6 Querying z/VM encrypted paging status
query encrypt
Encrypt Paging Settings:
Currently: Off
At IPL: Off
Ready; T=0.01/0.01 13:01:56
 
Note: The encryption can be activated at IPL time by including the ENCRYPT statement in the SYSTEM CONFIG file.
Using encrypted paging
Consider the following points regarding the use of encrypted paging:
•Make sure that CPACF is enabled on your LinuxONE server.
Support requires CPACF (no-charge Feature 3863) to be enabled on z14 hardware or later.
•Set ENCRYPT PAGING ON in System Configuration or use CP SET ENCRYPT PAGING.
•Protected the ephemeral key (of selected algorithm) that is generated by CP for the lifetime of the system for all guests. No key rotation mechanism exists in this PTF.
•Support is available in OFF (default), ON, and REQUIRED modes.
Per sponsor feedback on priorities, changing the algorithm in first deliverable requires an IPL.
•To prevent against timing attacks, TRSOURCE is not be permitted in the keygen section of the IPL processes.
•One key per z/VM partition; no SSI dependencies.
Performance considerations for guest relocation include reenciphering paging data.
•A mandate for 100% encryption uses ENCRYPT PAGING ON (at minimum) at IPL:
 – ENCRYPT PAGING ON provides the function, but can be dynamically toggled
 – ENCRYPT PAGING REQUIRED includes some usability concerns
 – Dynamic support can enable compliance, but proving it is difficult (draining volumes)
SSI and LGR implications with encrypted paging
Encrypted paging does not need to be enabled on all members of a Single System Image cluster.
Ephemeral keys are not shared; one ephemeral key exists per member. When a guest is relocated, its pages are decrypted before they are relocated to the target member. The target member reencrypts the guest’s pages by using its own ephemeral key.
Relocation domains can be defined per guests security requirements, such as the following examples:
•Access to hardware facilities, such as LinuxONE CPACF
•Encrypted paging in the hypervisor (requires LinuxONE partitions)
Important encrypted paging recommendations
Consider the following points:
•Test Encrypted Paging with ON before switching to REQUIRED.
•Consider one of the following options:
 – Switching from ON to REQUIRED in AUTOLOG1 (during System IPL)
 – SET ENCRYPT PAGING REQUIRED on a COMMAND statement for OPERATOR
•Have a backup System Configuration file (with setting ON) for emergency purposes.
•Double-check DR plans for the hardware feature availability of z/VM systems.
 
Note: If you configured REQUIRED on a system that does not support the feature, your system does not IPL.
 
3.4.3 Securing GUEST LANS and virtual switches
z/VM Virtual Switch supports access ports as USER-based or PORT-based. It can be VLAN-unaware, and the VSWITCH handles all VLAN tagging and trunk ports when it is VLAN-aware and processes its own VLAN tagging.
 
Note: The default configuration of the XCATVSW2 switch that is used by CMA defines it as VLAN-unaware.
Access to VLANs is controlled by the GRANT option of the CP SET VSWITCH command (MODIFY VSWITCH in SYSTEM CONFIG). For a user, a set of VLANs can be granted on a VSWITCH by listing them in the VLAN parameter. If more than one VLAN is specified, the PORTTYPE parameter must also be set to TRUNK. If a list of VLANs is given but PORTTYPE ACCESS is used, an error occurs, as shown in Example 3-7.
Example 3-7 SET VSWITCH GRANT with multiple VLANs and PORTTYPE ACCESS
set vswitch vlantst grant tcpip vlan 10 20 30
HCPSWS2847E PORTTYPE ACCESS is not allowed when the user is authorized
HCPSWS2847E for more than one VLAN
 
Note: Guest LANs are discouraged because they are more cumbersome to configure and less secure than a virtual switch.
3.5 Securing your communication
Security in individual layers might be enough to keep the data integrity, confidentiality, and availability at the destination, but it is important to secure the data while it is in transit during communication.
Some solutions can be implemented at the client side, but the organization cannot rely on client-side only security. Users can forget to update their security software or security operating system updates can unconsciously install malware on their devices that prevents the execution of the security software, or the users do not install the security software.
What the organization can do is make sure the communication between the client and the server is encrypted with a secure cryptographic protocol. New vulnerabilities are often discovered on cryptographic protocols, cipher algorithms, and protocol implementation, so the security team must be up to date about what is secure to be used, and new vulnerabilities that must be mitigated as soon as they are reported.
The IT infrastructure inside the organization is the responsibility of the organization, so all means to avoid security breaches are valid to protect the information. A well-planned network infrastructure also helps secure the data communication. The first point of contact with the internet should be the network security system. It controls the incoming and outgoing traffic to the organization’s network based on the application set of rules.
Separating the network into layers helps protect the information. Therefore, during network infrastructure planning, consider at least a layer for a DMZ, a layer for the web servers, a layer for the application servers, and a layer for database servers. This is not a rule and can be structured in different ways, but layering the network is important and must be considered when planning the network infrastructure.
Installing intrusion detection systems helps to monitor for attacks and parse audit logs that can use a large amount of storage and have a huge amount of information that a human cannot read and find a pattern for an attack at the same time it is happening. Intrusion detection systems help system and network administrators detect attacks and alert them about it while it shows the techniques in use to use possible breaches.
3.5.1 Encrypting your communication
There are several ways to move data into and out of a mainframe. Since the early 1970s, terminals connected to mainframes by using 3270 data streams. This high-performance protocol is still in use around the world and is how many developers connect to z/OS. By default, this data travels in clear text. Installations should evaluate the nature of the data that is transmitted over a 3270 connection and implement security measures, such as encryption, when warranted.
Enabling encrypted sessions requires configuration changes on both the host side and the client side. Fortunately, terminal emulators such as IBM PCOMM, IBM Host on Demand, and the open source x3270 emulators all support encryption of host sessions with simple configuration options.
Transport Layer Security/Secure Socket Layer
The Transport Layer Security/Secure Socket Layer (TLS/SSL) provides the processing capability that allows secure (encrypted) communication between two TCP/IP connection participants (one of which is a server or client application on the local z/VM host). Such communication may be secured by a static SSL connection or through Dynamic SSL/TLS, which allows a client or server application to control the acceptance and establishment of connections that are encrypted by using SSL.
For static TLS connections, no changes to a z/VM application server are necessary to participate in TLS. The application server does not perform any data encryption or decryption; this is handled by the z/VM TLS/SSL server.
Dynamic TLS connections are supported by the following z/VM TCP/IP application servers and clients, which were updated to accommodate this support:
•TCP/IP server
•SSL server
•FTP server
•FTP client
•Telnet server (Internal to the TCP/IP server)
•Telnet client
•SMTP server
Under the TLS protocol, the application server is always authenticated. To participate in a TLS session, an application server must provide a certificate to prove its identity. Server certificates are issued by Certifying Authorities (CAs), each of which establishes its own identity by providing a CA certificate. Server certificates and CA certificates are stored in a certificate database (also referred to as a key database) that is accessible to the TLS/SSL server.
Only TN3270 connections can perform client key exchanges, as shown in number 4 in Figure 3-2.
Figure 3-2 SSL scheme
You can configure the TLS/SSL server to meet industry and governmental cryptographic security requirements by updating the VMSSL keywords and parameters that are related to cipher suites and protocol levels. For z/VM V6.4 and onward support TLS 1.2, use this level of TLS/SSL for encrypting traffic to or within the hypervisor layer. Weaker cipher suites are disabled by default. If weaker encryption is required for compatibility purposes, it can be reenabled through the same keywords and parameters.
SMAPI ESM authorization support
With the PTF for APAR VM66167, SMAPI provides the following ESM interaction:
•When an ESM is present, programs can use the ESM for all SMAPI authorization decisions at the same granularity that is used with the SMAPI authorization mechanism. The ESM logs (or does not log) the decision that is based on its active policy, without SMAPI knowledge or intervention.
•When an ESM defers its authorization decision to SMAPI, one of the following actions is taken based on a configuration option:
 – The SMAPI authorization decision uses the authorization process. SMAPI calls the ESM to log the decision in the ESM-managed security log. SMAPI has no knowledge whether the ESM audit logging is enabled or disabled.
 – SMAPI treats the request as unauthorized.
Elliptic Curve Cryptography
With the PTF for APAR PI99184, the z/VM TLS/SSL server is enhanced to improve security through the enablement of Elliptic Curve Cryptography (ECC) cipher suites. ECC provides a faster, more secure mechanism for asymmetric encryption than standard RSA or DSS algorithms.
For more information (including PTF availability), see this website.
 
Note: For more information about how to customize and enable encrypted communications to and from z/VM, see Chapter 4, “Installing and configuring z/VM”, in The Virtualization Cookbook for IBM z Systems Volume 1: IBM z/VM 6.3, SG24-8147, and Getting Started with Linux on Z Encryption for Data At-Rest, SG24-8436.
3.5.2 z/VM Cryptographic definitions
When an LPAR is configured to benefit from hardware cryptography support, z/VM running in such an LPAR can use the hardware support for cryptographic operations to provide security to its guests. This section describes how to set up the z/VM definitions for guests running Linux on IBM LinuxONE.
By using the IBM LinuxONE cryptographic hardware, you gain security from using the CPACF and Crypto-Express6S through in-kernel cryptography APIs and for Linux on IBM Z, the libica cryptographic functions library. Using these features provides these benefits:
•File system encryption
•Communication encryption (to applications such as IBM HTTP Server)
•System security by providing advanced cryptographic functions
The way that z/VM provides this support is by granting access to the Adjunct Processor (AP) domains to the guests. From a system implementation perspective, an AP of a Crypto-Express5S feature is one of its internal cryptography engines (cryptography coprocessor units). AP designates to the processor, while AP ID specifies the number associated with it.
In a z/VM environment, it is expected that the LPAR running z/VM has access to multiple AP queues. There are two ways z/VM can provide access for the guests to the AP queues:
•Shared queue support (APVIRTual operand on the CRYPTO directory control statement)
Shared queue support provides for one or more Linux guest hardware encryption support for clear key operation. Clear key indicates that the key exists somewhere in the software stack in the clear. z/VM decides which AP queue is used.
•Dedicated queue support (APDEDicated operand on the CRYPTO directory
control statement)
Dedicated queue support for a guest must be used if the guest needs secure key support and relies on stored encryption keys in the hardware coprocessors. Secure key support means that the key can never be found in a readable form outside the actual cryptographic hardware. For guests that use dedicated-queue support, z/VM does not intercept the AP instructions in the queue and instead allows the guest to run the AP instructions under SIE. In this case, no virtualization of AP queues is done.
When a key is defined in an IBM LinuxONE crypto environment as a secure key, the key is protected by another key that is called a master key. A clear key has not been encrypted under another key and has no additional protection within the cryptographic environment. For clear keys, the security of the keys is provided by operational procedures.1
In an environment where the Linux guests on z/VM need only clear key support, use the shared queue support for hardware encryption. Even when z/VM virtualizes the AP queues for shared queue support, there must be at least one physical queue available for z/VM that is not dedicated to any guest.
Set up for a Linux guest to use cryptography cards
To enable a z/VM guest (Linux guest) to use the hardware cryptography support that is provided by the Crypto-Express6s feature, an entry must exist in the user directory of the Linux guest in the VM USER statement. This process is done by using the CRYPTO statement for each guest. For more information, see CP Planning and Administration, SC24-6271.
Guests with dedicated-queues support
For a Linux guest that needs access to dedicated-queues, the CRYPTO statement in the USER entry for the guest must contain which domain and which AP number is used, which means one or more AP queues are identified and reserved for this guest. There is no virtualization for these dedicated-queues, no sharing is done, and the queues are not available for other guests. With dedicated-queues, secure key and clear key operations can be performed by the Linux guest. The statement in the directory looks like the following one:
CRYPTO DOMAIN x APDED y
Where:
•DOMAIN x: x can be one or more domains that are defined for the z/VM LPAR.
•APDED y: y can be one or more APs (CEX6C cards) that are defined for the z/VM LPAR.
The combination of AP numbers and domain numbers should be unique across all cryptography users in the directory. Although you can use directory processing to specify the same AP and DOMAIN combination for multiple users, these users should not be logged on at the same time. If they are, more than one user might have concurrent access to the same AP queue. Directory processing does not enforce this restriction because duplicate definitions can be useful for backup configurations.
You can have multiple CRYPTO statements within one single user statement. However, if you choose different domains to different APs, all APs are available for all defined domains:
CRYPTO DOMAIN 10 APDED 1
CRYPTO DOMAIN 11 APDED 4
AP 1 and AP 4 are defined to the domains 10 and 12. It can also be shown as:
CRYPTO DOMAIN 10 11 APDED 1 4
The directory entry for the guests looks as shown in Example 3-8.
Example 3-8 Sample directory entries for dedicated-queues for cryptography access
USER EDI xxxxxxxx 64M 96M ABCDEFG
INCLUDE IBMDFLT
CRYPTO DOMAIN 004 APDED 005
CRYPTO DOMAIN 3 APDED 0 7
IPL CMS PARM FILEPOOL VMSYSU AUTOCR
OPTION LNKNOPAS QUICKDSP
MDISK 0191 3390 71 10 ZVMUSR MR
The privileged command, Q CRYPTO DOMAIN USERS shows the output that is shown in Example 3-9.
Example 3-9 Result of a Q CRYPTO DOMAIN command
q crypto dom users
AP 000 CEX6C Domain 002 available shared unspecified
AP 000 CEX6C Domain 003 available dedicated to EDI dedication
AP 000 CEX6C Domain 004 available dedicated to EDI dedication
AP 002 CEX6C Domain 002 available shared unspecified
AP 002 CEX6C Domain 003 available free unspecified
AP 002 CEX6C Domain 004 available free unspecified
AP 003 CEX6C Domain 002 available free unspecified
AP 003 CEX6C Domain 003 available free unspecified
AP 003 CEX6C Domain 004 available free unspecified
AP 005 CEX6C Domain 002 available free unspecified
AP 005 CEX6C Domain 003 available dedicated to EDI dedication
AP 005 CEX6C Domain 004 available dedicated to EDI dedication
AP 006 CEX6C Domain 002 available free unspecified
AP 006 CEX6C Domain 003 available free unspecified
AP 006 CEX6C Domain 004 available free unspecified
AP 007 CEX6C Domain 002 available free unspecified
AP 007 CEX6C Domain 003 available dedicated to EDI dedication
AP 007 CEX6C Domain 004 available dedicated to EDI dedication
Guests with shared-queue support
For a Linux guest that needs access to clear key cryptography operations, shared access to AP queues is the preferred way to implement this access. For this case, the CRYPTO statement in the USER entry for the guest needs to indicate that access to virtual queues is wanted. No domain and no AP queue must be specified. The Linux guest gets one virtualized card and one random virtual queue on one random virtual AP. The AP number and domain are chosen by z/VM and are not identical to the one for the z/VM LPAR.
 
Note: As of IBM LinuxONE, you can now specify a CRYPTO APVIRT statement in your System Configuration file. This specification allows the system administrator to designate specific AP domains that are attached to the LPAR as “Reserved for APVIRT”.
For this support, z/VM uses all available AP queues, which are not dedicated to other guests, and these are shared between all guests that use the shared support. If there are multiple AP types available for z/VM, then z/VM chooses the best AP type for acceleration for the Linux guest. When a type is selected, z/VM routes all cryptography requests from the guest to however many queues or cards of that type are available. The statement in the directory looks like the following example:
CRYPTO APVIRT
The AP queues number and the domain number, which are provided by z/VM to these two guests, are virtual numbers and do not correspond to the “real” domains and APs, which are used by z/VM to run the cryptography requests of these guests. The directory entry for the guests looks like what is shown in Example 3-10.
Example 3-10 Directory entry with dedicated and shared cryptography queues
USER GUESTL1 xxxxxx 256M 1G G
INCLUDE IBMDFLT
IPL CMS
MACH XA
NICDEF C200 TYPE QDIO LAN SYSTEM VSWITCH1
CRYPTO DOMAIN 9 APDED 2 3
-------------------- 3 line(s) not displayed --------------------
USER GUESTL2 xxxxxx 256M 1G G
INCLUDE IBMDFLT
IPL CMS
MACH XA
NICDEF C200 TYPE QDIO LAN SYSTEM VSWITCH1
CRYPTO APVIRT
To update the USER entry in the directory to contain the CRYPTO statement, you can use an editor and change all necessary USER entries. In an environment with DirMaint, proceed as described next to provide shared access to a Linux guest LNXSU1 for clear key operation and dedicated access to the AP queue with domain 11 and AP number 02 to LNXSU2 for secure key operation.
To change the directory for EDI to get shared access to the cryptography hardware, run the command dirm for EDI crypto. The pane that is shown in Figure 3-3 on page 48 opens. In this DirMaint pane, select APVIRTUAL (for the operand APVIRT in the CRYPTO statement) with any character and press F5 to submit the request.
--------------------------------DirMaint CRYPTO------------------------------
Query or update the current CRYPTO statement in the user's directory entry.
Select one of the following:
_ ? (Query) _ DELETE _ APVIRTUAL _ DOMAIN
For DOMAIN, enter one or more domain values (0 thru 255):
==> ----- ==> ----- ==> ----- ==> ----- ==> ----- ==> ----- ==> -----
==> ----- ==> ----- ==> ----- ==> ----- ==> ----- ==> ----- ==> -----
==> ----- ==> ----- ==> ----- ==> ----- ==> ----- ==> ----- ==> -----
==> ----- ==> ----- ==> ----- ==> ----- ==> ----- ==> ----- ==> -----
Optionally enter one or more APDEDICATED ap values (0 thru 255):
==> ----- ==> ----- ==> ----- ==> ----- ==> ----- ==> ----- ==> -----
==> ----- ==> ----- ==> ----- ==> ----- ==> ----- ==> ----- ==> -----
==> ----- ==> ----- ==> ----- ==> ----- ==> ----- ==> ----- ==> -----
==> ----- ==> ----- ==> ----- ==> ----- ==> ----- ==> ----- ==> -----
 
5741-A09 (c) Copyright IBM Corporation 1979, 2018.
1= Help 2= Prefix Operands 3= Quit 5=Submit 12=Cursor
 
Figure 3-3 DirMaint Crypto pane
3.5.3 Checking the cryptographic card definitions in z/VM
To verify that hardware cryptography support is available in z/VM and can be provided to z/VM guests, you can verify the definitions in the image activation profile of the LPAR in which z/VM is running. Then, you can check the definitions in the z/VM user directory to see what is already provided to the guests.
QUERY CRYPTO command
You can use the QUERY CRYPTO command to verify the cryptography support. Figure 3-4 shows the syntax for this command. For more information about this command, see CP Commands and Utilities, SC24-6268.
QUERY CRYPTO
>>--Query--CRYPto--.--------------------.
'-DOMains--.-------.-'
'-Users-'
Authorization
Privilege Class: A, B, C, E
Figure 3-4 QUERY CRYPTO syntax
The QUERY CRYPTO command displays the status of the cryptographic hardware and the status of AP crypto resources. This command shows only information about the subset of cryptography cards and domains as defined for the LPAR in which the z/VM system is running. The z/VM user that performs this command must have a high CP Privilege Class of A-B-C-E.
Example 3-11 shows the response to the QUERY CRYPTO command in z/VM environment where cryptographic units are available but no guests are assigned access.
Example 3-11 Crypto units available: z/VM guests do not have access to AP queues
CP Q CRYPTO
Crypto Adjunct Processor Instructions are installed
Using also the AP operand, you get more information about the installed AP queues, as shown in Example 3-12. In this example, domains are available for shared access (clear key) of the queues.
Example 3-12 Response to QUERY CRYPTO
q crypto ap
AP 000 CEX6C Domain 002 available shared unspecified
AP 000 CEX6C Domain 003 available free unspecified
AP 000 CEX6C Domain 004 available free unspecified
AP 002 CEX6C Domain 002 available shared unspecified
AP 002 CEX6C Domain 003 available free unspecified
AP 002 CEX6C Domain 004 available free unspecified
AP 003 CEX6C Domain 002 available free unspecified
AP 003 CEX6C Domain 003 available free unspecified
AP 003 CEX6C Domain 004 available free unspecified
AP 005 CEX6C Domain 002 available free unspecified
AP 005 CEX6C Domain 003 available free unspecified
AP 005 CEX6C Domain 004 available free unspecified
AP 006 CEX6C Domain 002 available free unspecified
AP 006 CEX6C Domain 003 available free unspecified
AP 006 CEX6C Domain 004 available free unspecified
AP 007 CEX6C Domain 002 available free unspecified
AP 007 CEX6C Domain 003 available free unspecified
AP 007 CEX6C Domain 004 available free unspecified
QUERY VIRTUAL CRYPTO command
The QUERY VIRTUAL CRYPTO command shows status information about the virtual cryptographic facilities of the z/VM guest. If the guest to which you are currently logged in to does not have access to cryptography queues, the response in Example 3-13 is shown.
Example 3-13 Guest does not have access to cryptography queues
CP Q V CRYPTO
No AP Crypto Domains are available
Trusted Key Entry support
The Trusted Key Entry (TKE) feature is a combination of workstation hardware and TKE Licensed Internal Code. It provides key management functions for operating systems, such as Linux on IBM LinuxONE and z/OS. Crypto-Express Cards are used to provide hardware support to most cryptographic functions through the Cryptographic Coprocessor Feature (CCF).
TKE provides a secure, remote, and flexible method for providing Master Key Part Entry, and to manage remotely PCIe cryptographic coprocessors for the crypto domains, that is, through smart cards or other secured devices. The cryptographic functions on the TKE are run by one PCIe cryptographic coprocessor.
The communication between the TKE workstation and IBM LinuxONE servers occurs through a TCP/IP connection, which is available through Ethernet LAN connectivity only.
 
Note: For more information about how to set up the TKE and managing master keys for crypto domains, see TKE Workstations User’s Guide, SC14-7511.
To enable guests running under z/VM benefit from cryptographic hardware, crypto domains, and crypto coprocessors must be attached to z/VM LPARS through HMC dialogues. After this process is done, crypto domains can be dedicated to or shared with other LPARs.
3.6 z/VM connectivity
Connectivity in z/VM can be provided by customizing TCP/IP. The TCP/IP VM provides the primary TCP/IP service that is called the stack. The stack controls the network interfaces, such as Open Systems Adapter (OSA), and supports the application programming interfaces (APIs).
For more information about how to set up and define the stack, see Chapter 19, “Configuring the TCP/IP Server”, in TCP/IP Planning and Customization, SC24-6331.
3.6.1 DEVICE and LINK statements
For TCP/IP to use network devices on z/VM, you must ensure that the device addresses are attached to the TCP/IP VM by doing one of the following actions:
•Modify the DTCPARMS file to enable the necessary devices to be attached by using the :Attach. tag.
•Add the appropriate DEDICATE control statements to the TCP/IP VM’s directory entry.
z/VM does not require a device definition in the system configuration file or HCPRIO. The device attributes are determined automatically during device initialization.
Example 3-14 shows the Device and Link configuration statements for an OSA device that is found in the PROFILE TCPIP file.
 
Note: Although system configuration is not required from an I/O standpoint, you might need to code RDEVICE statements in SYSTEM CONFIG to set up the Equivalence ID (EQID) for the QDIO devices in an SSI environment.
Example 3-14 DEVICE and LINK statements for an OSA device in the PROFILE TCPIP
DEVICE DEV§04B0 OSD 04B0
LINK OSA01 QDIOETHERNET DEV§04B0 PATHMTU 1500 VLAN 20
VLAN
In z/VM environment, the virtual servers that are connected to each other through a virtual LAN (VLAN) which eliminates the requirement for any physical cabling or external networking connection among them. Functioning as an internal LAN, it moves data at memory speed between the virtual servers with high throughput and low latency communication path.
VSWITCH
The z/VM Virtual switch (VSWITCH) is built on guest LAN technology and consists of a network of virtual adapters that can be used to interconnect guest systems (see Figure 3-5). The virtual switch can also be associated with one or more IBM Open Systems Adapter-Express (OSA) ports. This capability allows access to external LAN segments without requiring an intermediate router between the external LAN and the internal z/VM guest LAN.
Figure 3-5 z/VM Virtual switch (VSWITCH)
HiperSockets
IBM HiperSockets are an extension to the queued direct I/O (QDIO) Hardware Facility, providing a microcode only, low latency communications vehicle for Internet Protocol (IP) inter-program communication (IPC). With the use of HiperSockets, a program can directly communicate with a program running within the same LPAR and across any LPAR within the same central processor complex.
3.6.2 HiperSockets VSWITCH Bridge
Another type of connectivity is available with the IBM LinuxONE using z/VM V7.1. The HiperSockets VSWITCH Bridge was introduced to allow an internal HiperSockets network to be extended outside the IBM LinuxONE processor complex. By using this capability, a network configuration can be greatly simplified.
Consider the following points:
•Guests of z/VM that need access to VSWITCH and HiperSockets hosts must be attached to only connection types to have access to both, without routing.
•HiperSockets networks in different IBM LinuxONE CPCs can be logically connected to each other, which means that z/VM guests that use LGR can treat the HiperSockets networks in different CPCs as the same because traffic is bridged between them.
The HiperSockets VSWITCH Bridge does not require a TCP/IP stack to function. The capability is provided by the z/VM CP system service that supports VSWITCH operation. The bridge is set up by defining a HiperSockets connection as an UPLINK port on a VSWITCH. The HiperSockets VSWITCH Bridge takes care of all issues relating to moving a frame from QDIO OSA frame type to IQDIO HiperSockets mode (and vice versa).
 
Note: For more information, see IBM HiperSockets Implementation Guide, SG24-6816.
3.6.3 Security considerations
Because HiperSockets often are an isolated network with no exposure outside the
IBM LinuxONE CPC, security considerations exist for the use of the HiperSockets VSWITCH Bridge. Bridging a HiperSockets CHPID that is used for secure cross-system traffic within an IBM LinuxONE CPC to an external network connection might be a cause of concern that the secure traffic may be exposed. However, because HiperSockets are a LAN segment, security considerations exist whether they are transmitting data in-memory or over OSA CHPIDs.
 
Note: The HiperSockets-VSWITCH Bridge is not a promiscuous bridge; it does not passively transfer all traffic appearing on the HiperSockets onto the VSWITCH or vice versa. It actively sends only frames with destinations that are unknown on the HiperSockets to the VSWITCH. Likewise, the VSWITCH sends only frames to the HiperSockets for addresses that the HiperSockets registered to the VSWITCH.
Because of the way the function works, it is not feasible that secure traffic on a HiperSockets CHPID might be exposed by the HiperSockets-VSWITCH Bridge. Consider the following points:
•The function copies frames only to destinations that are unknown on the HiperSockets over to the VSWITCH.
•The HiperSockets network traffic analyzer (NTA) function, which the only method that is available for tracing or ‘sniffing’ traffic on a HiperSockets, only functions with Linux running natively in the LPAR authorized for NTA.
The number of HiperSockets networks that are available in an IBM LinuxONE CPC makes it possible that a dedicated HiperSockets virtual network might be used for the HiperSockets VSWITCH Bridge function without any perceived risk to the traffic that is carried on HiperSockets that are in use.
3.7 Remote Spooling Communications Subsystem
Remote Spooling Communications Subsystem (RSCS) Networking for z/VM is a networking program that enables users on a z/VM system to send messages, files, commands, and jobs to other users within a network. It is an easy way to transfer data files (as spool files) among z/VM systems or other systems, such as, z/OS. It also acts as a print server for remote printers that are attached to other z/VM systems or a Internet Protocol network. Through RSCS, users can send and receive messages, files, issue commands, and print and submit jobs within their networks.
RSCS can communicate with system nodes that are running under the control of network job entry (NJE) compatible subsystems, such as:
•JES2 or JES3
•RSCS
•VSE/POWER
•IBM AS/400® Communications Utilities
•Products that provide NJE functions for Linux or IBM AIX®
NJE is the native peer-to-peer networking protocol for IBM mainframes running RSCS. It is flexible so that you can customize it to meet the changing needs of your installation and network. Using exit facilities and control files, such as the configuration file and events file, you can set up and tailor the way RSCS works and establish security rules by using specifics exits.
Since the earlier z/VM versions, the encryption support of TCPNJE traffic was implemented. A TCPNJE link connects the local RSCS system to a remote NJE system through TCP/IP. Because TCPNJE uses the z/VM TCP/IP stack, this configuration also supports encryption by using the TLS/SSL server, as described in 3.5.1 “Encrypting your communication” on page 42.
For more information about RSCS and the NJE communication protocol, see Best Practices for NJE on z/VM: Security Configuration Steps for RSCS and VMBATCH.
Main functions
RSCS is a subsystem that can perform the following functions:
•Handle data being sent to, from, or through z/VM systems.
•Store and retrieve input and output data files on the z/VM system spool.
•Use communications equipment to transfer data between its z/VM system and remote users, devices, and other systems.
How RSCS fits into your installation
RSCS uses the z/VM system spool to manage file transfers. It uses the spool for temporary file storage and to store files being transferred between its local system and remote users, devices, or systems.
To manage files that are spooled to remote nodes, RSCS relies on tag information. A spool file tag becomes part of each data file that is spooled to RSCS. The tag contains information that describes where the file came from (origin information) and where it is going (destination information).
RSCS EXITS
RSCS exits are used to restrict the sending and receiving files of programs that can affect the performance of the system, such as executable files that can have malware. Using exit facilities and control files, such as the configuration file and EVENTS file, you can set up and tailor the network where RSCS functions. You can use the exit facility to modify RSCS processing to meet any special functional requirements for your installation.
 
Note: For more information, see RSCS Networking Exit Customization, SC24-6317.
Security aspects
The Gateway Security Modification (GSM) is a feature of RSCS that can reject any files that go through RSCS. You can create control files to restrict certain users from sending files to a specific system and issue monitor commands of RSCS.
As a preferred practice, create a rule so that the users have permission to send/receive files to other systems while restricting the areas that they can use.
Table 3-1 lists the main security packages that must be implemented in your environment.
Table 3-1 Some of RSCS Exits focusing some security aspects
Package name
Main function
Exit
Gateway security
modifications (GSM)
Controls the data traffic.
Gateway programming
interface, Exit 0, Exit 1, Exit
14, Exit 15, Exit 19, Exit 21,
Exit 29, and Exit 32
Selective file filter (SFF)
Purges unwanted files.
Exit 0, Exit 1, Exit 15, Exit
21, and Exit 29
Simple security package (SSS)
Limits file traffic or user ID usage.
Exit 0, Exit 1, Exit 14, Exit
15, Exit 19, Exit 21, and Exit 32
RSCS advantages
In a multisystem network, because the systems are interconnected, data can be moved through and between them from any system and to any system. RSCS running under z/VM (in addition to what it can do in a single-system environment) can do networking.
To users, networking means they can perform the following tasks:
•Exchange data with users on the same system.
•Exchange data with systems and users at other locations.
•Send jobs to other systems for processing.
•Direct processed output to devices, such as printers and punches, that are connected to another system.
Employees can get that data that they need from other systems. When work passes from one phase to another, moving as it does from department to department, RSCS can transfer data from one employee to the next, from one system to another system. Employees can do the following actions:
•Correspond electronically.
•Use programs on another system to process their jobs.
•Send jobs from a remote workstation at their location to the local or to a remote system.
•Direct output to RSCS-controlled 3270 printers or ASCII devices from jobs they submitted to either local or remote systems.
•Send or receive output for other system-controlled printers through RSCS.
•Send an output file that they created for another employee to print on that employee’s system.
You can buy and locate resources (processors, computer programs, and I/O devices) to fit your business needs, whether by departments or regions. Because these resources can be shared, you can distribute the workload of your business and improve your employees access to these resources. This can lead to greater efficiency and productivity in your business.
 
Note: For more information, see RSCS Networking Planning and Configuration, SC24-6320.
 
1 For more information, see Hardware Crypto for IBM Z & LinuxONE.
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.144.38.92