8.4 Opening the doors

Now that we have covered some physical and virtual security aspects, let's go to the next step in protecting a machine: allowing users entry.

When StoreCompany created its Linux-on-the-mainframe environment with Linux images and z/OS working together on one machine, one risk (arguably very small) it considered was that of a Linux image being taken over. What could then happen? The Linux image has a connection to z/OS, and someone could theoretically get access to z/OS resources. However, like most z/OS systems, StoreCompany's z/OS resources are under the control of the RACF security manager. It would not be possible to take over z/OS.

If someone very knowledgeable got as far as taking over a Linux image with a connection to z/OS, that person could send commands to z/OS. But the effect of such commands is limited to what the Linux image is authorized to do. For example, if the image belongs to user George, it might be authorized to look at all files associated with George's orders. However, if George's image asks z/OS for the payroll, z/OS recognizes that the image has no authorization to look at this file and will deny access. Hence, with the standard authentication and authorization of the mainframe in place, even if an image were taken over, it would have a very limited scope of access to other systems.

This section covers considerations of allowing users access to the system: authorization, access control, and secure network communications.

8.4.1 Identification and authentication

Identification and authentication provide a first level of protection when permitting entry to the machine. Users identify themselves and give some piece of information that authenticates who they are. For example, users identify themselves by giving a user ID and then give the password associated with that ID.

Identification and authentication in general can be done by many different means, such as certificates, user IDs, and passwords.

When the machine knows who you are, it can decide what you are allowed to do this is authorization. For example, a user ID and password combination gives users access to files, with which they are thus authorized to work. In this case, the files are password protected. The file system provides the security service of allowing access to the file only when presented with the correct password. This method was typical of, for example, batch-oriented S/360 systems. This method has some drawbacks in a large multiuser system, however:

• All files (or programs, or other resources) have their own authentication code. If you want to change it, you must recompile all the programs or all the resources that reference the method.

• If multiple users need access to one file, they must all know the password. It is then hard to tell who did what with that file.

• If users need access to multiple files, multiple passwords are needed.

Instead of permitting access on a per file basis, modern operating systems (like z/OS and Linux) authenticate the user to use an identity. Identities are typically stored in a user registry. Both Linux and other mainframe operating systems make use of registries.

For z/OS and z/VM, the user registry of choice is the Resource Access Control Facility (RACF). (Note, however, that RACF for z/OS is different from RACF for z/VM.) RACF is the chief function of the mainframe's Security Server and incorporates user identification and authentication, as well as access control, which is discussed in 8.4.2, "Access control." In a Linux-on-the-mainframe context with Linux images running under z/VM, you can use RACF to secure z/VM user IDs and passwords.

Instead of each program having its own authentication code, many Linux distributions now come with Pluggable Authentication Modules (PAMs). If a program is PAM enabled, youcan easily switch between several authentication methods. If the Linux images with connectors to z/OS use PAMs, it might be possible to share user ID definitions and passwords with the Linux images.

Example of centralized authentication services

On Linux, the Lightweight Directory Access Protocol (LDAP) can be used with a user registry. An example of how to use PAMs and LDAP to share existing z/OS RACF data is shown here.

An LDAP server can be any general-purpose distributed directory server and can contain many different types of information, from distributed application descriptions and configuration information to user and group definitions.

Imagine an environment like that of StoreCompany with many Linux images running on a mainframe where z/OS is also running. User Peter has an account on z/OS as well as on several of the Linux images. How can you manage many users like Peter from a central point? Using a user registry is one answer. Assume user information is stored centrally in an z/OS LDAP server. PAMs can then be configured to pass authentication requests to the LDAP client, and from the LDAP client to the server. Thus you can share existing RACF information with the Linux systems and keep, for example, passwords protected by RACF, using a special feature of the z/OS LDAP server.

If z/OS runs on the same hardware as the Linux images, HiperSockets communications can be used. HiperSockets is an internal communication method with no physical network parts. Thus no information can be "sniffed." This scenario is illustrated in Figure 8-4.

Figure 8-4. RACF information can be shared with Linux systems through using PAM and LDAP

8.4.2 Access control

The use of access control has migrated from a mainframe-only environment to become an integral part of many platforms' security solutions and their security policy management systems. As Linux continued to mature and the number of applications grew, the availability of and need for resource access control became a critical component in the deployment of Linux-based environments.

Access control mechanisms on Linux systems

"Who can do what, where?" is the task that access control performs. There are two types of access control mechanisms:

• Discretionary Access Control (DAC)

• Mandatory Access Control (MAC)

DAC can be used to manage access control in its simplest form in a low-risk environment. The supplied Linux DAC is known as "user," "group," and "other" permission bits on the file system. These bits determine what user or group is allowed to read, write, or execute a particular resource (file, directory, or device). For example, when you access a printer, you are actually writing to a file in the file system. This can be controlled through the "user," "group," and "other" bits. In the simple server consolidation case, this may well be enough.

MACs are used when securing highly confidential data. The user has no control over the classification or labeling of the resources. The security policy requires a security manager, human or automated, to assign sensitivity labels to every subject (users and programs) and all objects (files, directories, and devices). MACs, along with the proper labeling, make up the core of a multilevel security (MLS) policy. The automated implementation of rigorous MACs is found in sophisticated policy management systems where risk must be minimized.

Using DAC, users can choose to share or give away access to a resource under their control. With MAC, this decision is out of their control. At a minimum, groups should be identified and group permissions used to isolate security functions such as user administration, audit, system and application maintenance, system backup, kernel and key operating system executables.

Access control lists (ACLs): Access control lists (ACLs) are another form of the more robust access control case, MAC. They allow the user more flexibility to manage individual resources, but require more knowledge of the system. ACLs give a security administrator the ability to control each user's access at an individual resource level. They list users and what they can do. Taking the "user," "group," and "other" mechanism to the next level by including ACLs provides an environment with less risk, but yields more system administration overhead.

Certain Linux journaling file systems, such as ext3, are ACL-enabled. These are included in, for example, the SuSE SLES 8 distribution.

Tools for access control

For an access control solution to successfully enforce the access control list (and hence the access policy of the system), it must be closely integrated with the kernel's decision points to avoid various system attacks or spoofing attempts. In the vendor arena, access control solutions are provided, for example, by IBM Tivoli Access Manager and CA's eTrust suite. See 25.6, "Tools Web sites" for a list of tools and their Web sites.

In the Open Source area, BestBits, LoMAC, SE Linux, and others all provide various levels of access control functionality and can run on a zSeries Linux server.

8.4.3 Secure and encrypted communication

Linux provides some potentially useful schemes for more secure communication which are important for today's e-business environment. In this section, we will cover the most important aspects of secure communication:

• Secure physical communication using Secure Socket Layer (SSL), Virtual Private Network (VPN), and mainframe cryptographic functions

• Secure virtual communications over HiperSockets and other virtual communication connections

SSL and key setup

The Secure Sockets Layer (SSL), which is the core technology used to secure Internet transactions, uses cryptography both for authentication of clients and servers and for data confidentiality.

One shortcoming of the user ID and password (basic authentication) model is that the password has to be passed from the end point, where the user is, to the physical location where the application and security registry reside, which may be far away. It is important to ensure security of the password in transit. On the mainframe, the SSL protocol can be used to encrypt the password while in transit.

The Open Source version, OpenSSL, is included in many distributions and can be used with Web servers, such as Apache. OpenSSL is a robust, commercial-grade, full-featured, and Open Source toolkit that implements the Secure Sockets Layer and Transport Layer Security protocols, as well as a full-strength general-purpose cryptography library. On the mainframe, you can use the hardware cryptographic functions for authentication through OpenSSL.

SSL is a protocol for transmitting documents securely through the Internet. SSL works by using a public key to encrypt data that are used to agree on symmetric encryption keys. These keys, in turn, are used to encrypt data that are transferred over the SSL connection. SSL has several characteristics that can be used by an e-commerce application to communicate with large numbers of users via common Internet browser software:

• SSL can be used to identify and authenticate (with a high degree of trust) server applications to users of the application. For example, this function would be important for a Web marketing application that requests a customer's credit card number. The customer wants to be assured that the application is the one intended and not a "Trojan horse" imposter that is stealing credit card numbers. SSL provides this highly useful security function.

• SSL can be used to establish a private cryptographic communication channel through the Internet between the communicating parties (for example, the customer on the Internet and the Web application server). This channel enables credit card numbers to pass from the customer to the marketing application without being observed. Note that VPNs, which we will discuss later, also provide Internet communication privacy. The difference is that VPNs are generally used for point-to-point communication links that can be shared by multiple applications and that continue for a longer duration than those typically seen with common browsers.

• SSL can be used to identify and authenticate (with a high degree of trust) users of applications to Web application servers. This function is most useful when the application provides function that requires the user to be known to the application. An example is when the application has administrative support function that needs to be individually authorized for execution by only specified individuals (such as payroll functions).

SSL has emerged as the preferred method for securing Web-based transactions on the Internet. It is widely supported in browsers and most Web servers. The first two functions are in common use worldwide, while the third (user identification and authentication using X.509 version 3 digital certificates) is being applied in an increasing number of cases.

For a description of how SSL works, see http://developer.netscape.com/tech/security/ssl/howitworks.html.

Virtual private networks

Virtual private networks (VPNs) allow remote users safe access to critical system resources and provide safe remote communication, for example, for systems management. VPNs provide a valuable means of doing remote system management securely over the Internet.

VPNs enable encrypted connections from one system to another over the Internet. The part that constitutes the actual connection over the Internet is encrypted, often using OpenSSH (see Figure 8-5) or the IP Security Protocol (IPSec).

Figure 8-5. Virtual private networks send data over the Internet securely encrypted with SSH or IPSec

There are several uses of VPNs: hardware-based VPNs (usually for encrypting routers), firewall-based VPNs (which include address translation, authentication, alarms, and logging), and stand-alone software VPNs (ideal to use when the connection endpoints are not controlled by the same organization).

Virtual networks should be planned with the same care and attention to security as would be taken for a real, physical network. Networks, virtual or real, must be designed and implemented so that no unauthorized access to data or resources is possible. For system administration tasks, a separate network with secure access is recommended. The ability to define multiple virtual routers gives the ability to completely isolate traffic moving in and out of the S/390 or zSeries server. Highly secure communication between LPARs can be easily handled by using zSeries HiperSockets connections.

Available virtual communication paths under z/VM are summarized in Table 8-1. For more details about them, see Chapter 10, "Communicating in a Virtual Environment."

Table 8-1. Available virtual communication paths with z/VM

Communication	Functionality
Guest LANs	Guest LANs provide multipoint any-to-any virtual shared media connections between guests. As many Guest LANs as are needed can be defined and used simultaneously. To prevent unauthorized connection to a Guest LAN, the creator of the LAN can define it to be restricted, permitting only specific virtual machines to connect to it.
vCTC	vCTC emulates a real CTC adapter (IBM 3088). Each virtual machine defines a vCTCA and then uses the CP COUPLE command to connect the two endpoints. I/O operations to the device are intercepted by the CP, which moves the data between two different virtual machines. Again, data are moved at near memory speeds.

Whenever you use virtual communications technology, there may be no need to encrypt the traffic because the information never leaves the machine. An overview of secure communications can be found in the whitepaper z/VM Security and Integrity, GM13-0145. It is available at http://www.ibm.com/servers/eserver/zseries/library/techpapers/gm130145.html.

Cryptography

The use of cryptography has become a common requirement in today's computing environment. Cryptography can be used for confidentiality, authentication, and data integrity. Cryptography is crucial for security on the Internet, banking and finance, and e-business.

Confidentiality is gained when a cryptographic algorithm is used to make the data available to only a trusted group of users. The data are transformed from clear text into cipher text by using an encryption algorithm and a key. The data are unintelligible in cipher text form and can be decrypted only using the correct algorithm and the correct decryption key.

One use of cryptography on Linux on the mainframe is digital signatures. Earlier, authentication was thought of as being done by users entering his or her user ID and password. This is still valid today, but the trend goes towards using digital signatures. This relatively new technology is available and deployable on Linux on the mainframe. Although there are several methods for digital signatures, the most common method in use today is RSA public key cryptography.

Another use of cryptography is the validation of data integrity. Integrity can be validated through the use of a one-way cryptographic function. A hash function is sometimes used by the owner of critical data to come up with a "digest" of the data. Any other user or program can then validate that the data have not been modified by using the same hash function and obtaining the same digest.

zSeries and S/390 servers offer specialized processors for cryptographic operations. In an ISP or ASP environment such as ISPCompany, cryptographic procedures are frequently used for highly secure TCP/IP connections between the server and a user somewhere on the Internet. Applications for firewalls, Web serving, and mail serving also have the requirement to protect data.

Linux and mainframe cryptography: Linux on the mainframe can use the mainframe cryptographic services, thanks to a single device driver for both the newer IBM PCI Cryptographic Accelerator (PCICA) and the older PCI Cryptographic Coprocessor (PCICC). The new PCICA feature is designed to address the high-performance SSL needs of e-business applications. It provides accelerated performance of the complex RSA cryptographic operations used in the SSL protocol.

The older PCICC allows implementation of different cryptographic algorithms and can be used for specialized financial applications, or for secure long-term storage of keys and secrets. Both PCICA and PCICC have earned Federal Information Processing Standard (FIPS) 140-1 Level 4 certification, the highest certification for commercial security awarded by the United States government.

To use a cryptographic coprocessor, the operating system must be able to recognize application requests for cryptography, pass the requests to the cryptographic hardware, and return the result to the application. The driver available for Linux on zSeries and S/390 exploits the PCICA and PCICC cryptographic hardware for the algorithms used by SSL (see Figure 8-6). This exploitation results in significant performance improvements for SSL transactions.

Figure 8-6. The cryptographic device driver for Linux on the mainframe enables openLDAP or openSSL requests

The code for cryptographic support and associated functionality is included in, for example, the SuSE SLES 8 distribution.

Virtual cryptography support Linux and z/VM: The PCICC and PCICA cards can be shared and used by any number of Linux guests as shown in Figure 8-7. Each operation is discrete and independent of those that precede or follow it. z/VM manages the queue of requests so that a guest can see only its own request, as with a shared processor or a shared channel.

Figure 8-7. Virtualized cryptographic functions

ISPCompany example: secure networking

In a service bureau situation such as at ISPCompany, where there are physical farms of machines in separate caged areas, there is sometimes a LAN that connects all the customer machines. Assuming a client were to exchange the standard network adapter for one that allows all the network traffic to be read, the client could read not only his or her own traffic but also everybody else's.

To prevent this, ISPCompany has point-to-point connections from the incoming data source to the different machines. This costs more, but is more secure than a LAN.

When ISPCompany virtualizes the adapters by putting its customers into z/VM, there is no physical adapter for intruders to sniff. z/VM does not let guests see any traffic other than their own when they share an adapter.

By using HiperSockets, ISPCompany can eliminate the physical risk of someone tapping into the network. Other benefits of HiperSockets include high speed of transfer and close to zero latency. Some savings can be made on not having actual cables and other hardware needed for the physical network.