S 4.212 Protection of Linux for zSeries

Initiation responsibility: IT Security Officer, Head of IT

Implementation responsibility: Administrator, Specialists Responsible

On zSeries systems, it is also possible to use the Linux operating system. In this case, module S 3.102 Servers under Unix and module S 3.204 Unix client must be implemented to secure the operating system. Furthermore, the following describes some zSeries-specific particularities that must be taken into account.

Linux operating modes on zSeries

Three different Linux operating modes are possible on zSeries systems.

Linux native on zSeries hardware

The Linux operating system is operated as a single system on the zSeries hardware. This means that the entire zSeries hardware is used by the Linux system.

Linux on a zSeries LPAR

In this mode, Linux is operated on an LPAR (logical partition) on the zSeries machine. The LPAR mode allows several operating system installations to be operated independently on the same zSeries hardware. Each partition behaves like independent hardware. z/OS or Linux, among others, can be installed as the operating system on these LPARs.

Linux under the z/VM host system

Several Linux installations can be operated on a zSeries computer or on an LPAR under the z/VM host system. The z/VM provides virtual machines in which each Linux installation can be operated independently of one another.

Securing the terminals

The SEs (Support Elements) and the HMC (Hardware Management Console) must be protected as recommended in safeguard S 4.207 Use and protection of system-related z/OS terminals.

Securing Linux under z/VM

The following recommendations should also be taken into account for the operation of Linux under z/VM:

• The most recent patches for z/VM must be installed. It must be ensured that the z/VM systems are not outdated.
• The z/VM system administrators are granted a very wide range of authorisations. Administrators can set up additional virtual machines and delete existing ones under z/VM. This means an administrator is in a position of trust, and the administrator must be aware that he/she is jointly responsible for the security of the systems.
• The default login password and the default minidisk password must be changed immediately after installing a z/VM system.
• The virtual machines defined in z/VM should only be provided with the resources, for example minidisks, addresses, etc., necessary to perform their particular tasks. Strict separation of the virtual machines must be maintained.
• Only the services needed should be started in z/VM. Unneeded services must be disabled.
• The z/VM security administration must be performed using RACF for z/VM. RACF for z/VM functions as a security manager and can only manage the rights of the z/VM users. Furthermore, virtual machines, minidisks, and (if desired) terminals should be protected using RACF resource profiles. Access to these resources should only be granted to those users who need these rights in connection with their tasks. However, RACF cannot manage the rights of the Linux users or user access to system resources within the Linux operating system. Linux users are controlled by the normal Linux security mechanisms following successful activation of the virtual Linux system. z/VM system commands that are critical to security (such as CP DIAL, for example) should be protected using RACF.
  Use of the DIRMAINT utility should be considered for the administration of the files and directories in z/VM. It permits clear and simple administration of the user directories and therefore helps to prevent administration errors. DIRMAINT's security mechanisms should always be based on RACF for z/VM. Commands and messages in the framework of the DIRMAINT administration should be subject to audit control.
• The journaling function of z/VM and the audit functions of RACF should be used for audits (see also S 2.291 Security reporting and security audits under z/OS).
• The usual standard mechanisms in Unix and Linux should be used to secure TCP/IP connections. Furthermore, consideration should be given to using the KERBEROS Authentication Services or Secure Socket Layer (SSL) in addition to the standard mechanisms. Both are supported by Linux.
• The Linux definitions should be configured so that the calling of recursive functions cannot result in overloading the operating system (see also T 3.69 Incorrect configuration of Unix System Services in z/OS).

Linux authentication via z/OS RACF

Consideration should be given to authenticating Linux users from a central z/OS RACF using LDAP (Lightweight Directory Access Protocol) and a Linux PAM (Pluggable Authentication Module). This can significantly reduce the complexity of administering the IDs, especially when there are a large number of Linux systems to be administered.

Linux and cryptographic hardware on zSeries machines

zSeries systems can also be equipped with optional cryptographic processor cards of type PCICA (Peripheral Component Interconnect Cryptographic Accelerator) or PCICC (Peripheral Component Interconnect Cryptographic Coprocessor). These cards serve to improve the performance of the cryptographic functions and to securely store digital keys. Both cards are also supported by Linux. Since Linux does not support the CCF (Cryptographic Coprocessor Feature), consideration should be given to using these cryptographic cards. They can be used in all of the installation modes described above. In z/VM, the cryptographic cards can be used by several Linux systems simultaneously and independently of each other.

Linux communication on zSeries hardware

The communication between operating systems, e.g. z/OS and Linux, which are either installed in the LPAR mode or under z/VM on the same zSeries hardware should be performed over internal channels, i.e. over HiperSockets or virtual channel-to-channel (CTC) connections. They allow rapid TCP/IP connection between the operating system installations. When compared to communication over the local network, they provide lower error rates and fewer opportunities for attacks since the information flows from system to system in the same hardware.

Review questions:

• Are the most recent patches for z/VM on zSeries systems always installed?
• Have the default login password and the minidisk password been replaced with new passwords after installing z/VM on zSeries systems?
• Have all unneeded services been disabled under z/VM on zSeries systems?
• Are the journaling function of z/VM and the audit function of RACF used for audits on zSeries systems?
• Is the communication between operating systems (z/OS or Linux), which are either installed in the LPAR mode or under z/VM on the same zSeries hardware, performed over internal channels?