Security of Linux on zSeries

1. Security of Linux on zSeries

2. Objectives • List the three modes in which Linux can be run on zSeries. • State what can be shared with a Linux in native mode environment. • State which feature is responsible for ensuring each guest is given access to only those resources allotted to it for Linux in LPAR mode. • List the five main considerations that need to be taken into account when assuring a customer about the security of the Linux in LPAR environment. • Describe how memory and processor sharing can be achieved while maintaining the security and isolation of individual guests in a Linux for LPAR environment. • List the five main security considerations of running Linux on z/VM.

3. Objectives • State which feature is responsible for ensuring each guest is given access to only those resources allotted to it for Linux on z/VM. • Describe how memory and processor sharing can be achieved while maintaining the security and isolation of individual guests in a Linux for z/VM environment. • List and briefly describe six security considerations to create a secure Linux environment. • Briefly describe NAT and list three types of NAT. • Briefly describe packet filtering. • Briefly describe LDAP and how it works. • State how the slurpd command works. • State how data is organized in an LDAP directory. • State how PAM works with LDAP to create secure and easily accessible user IDs and passwords.

4. Running Linux in native mode • The simplest security scenario is with Linux running in native mode. • Here Linux is the only operating system on the hardware. • Therefore, all internal resources (processors, memory, channels) are dedicated and there are no concerns about sharing these resources with other systems. • It is still possible to share external resources such as DASD with other mainframe systems, but that would imply the same problems as if the Linux systems were running on a hardware platform other than zSeries.

5. Running Linux in LPAR mode • With Linux running in multiple LPARs things get more complicated as the PR/SM microcode used to share the zSeries resources needs to be factored into the security scenario. • PR/SM ensures that each LPAR uses only the resources that have been allocated to it. • If for security purposes, total isolation of a partition is required, the system can be configured so that no resources are shared with other partitions. • However, this eliminates the benefit of resource sharing. • Must strike a balance between separating data and applications of individual customers and utilizing resource sharing.

6. Considerations with virtualization • To make the principle of resource sharing acceptable for these customers, some questions need to be answered: • Is there an official certification that the processes of the PR/SM microcode are secure with zSeries architecture, and features like HiperSockets? • If CPs are shared between LPARs, is there any risk that one LPAR can influence the operations in another LPAR? • What is the risk if memory is reconfigured from one LPAR to another? • How can the dedicated and secured use of peripheral devices be assured, if shared channels and control units are used? • Should there be a secure administration access to Linux for zSeries systems, especially to those that are logically placed in DMZs?

7. 1. Certification with PR/SM • IBM eServer zSeries 900 server is the first server to receive the Common Criteria EAL5 certification level (evaluation assurance level 5) for the security of its logical partitions – rated by CSC Ploenzke of Munich, Germany, under license from the German Certification Body, Bundesamt fuer Sicherheit in der Informationstechnik (BSI), Bonn, Germany. • Certifies that PR/SM can separate and isolate partitions as if they were running on physically separate systems by performing: • Identification and authentication • Audit and accountability • Access control

8. 2. Processors in a LPAR environment • LPARs running on zSeries hardware can use either dedicated PUs, or shared PUs. • CPs or IFLs (but not both in the same LPAR) can be used to run Linux workloads. • IFL can only be used to run native Linux, or z/VM V4 with Linux guest systems. • z/OS LPAR requires CPs, a Linux LPAR (which means native Linux, or z/VM V4 with Linux guest systems) can run either on CPs or on IFLs. • z/OS LPARs do not share processors with native Linux or z/VM LPARs, but it can run Linux in LPAR mode on a CP shared with a z/OS LPAR (for testing LPARs and small functions). • This sharing of resources can be managed through the Intelligent Resource Director (IRD). • IFLs can be shared between two or more Linux LPARS, but not between Linux and z/OS LPARs. • A shared processor is given to one of multiple LPARs, each for a predetermined amount of time, then upon completing the task or receiving an interrupt it is given to another. • For the duration of timeslice (period of allotted time), only one LPAR has access to the processor.

9. 3. Memory in a LPAR environment • Memory is not shared between LPARs, but the total amount of memory installed is divided among the LPARs. • Logical storage is allocated when the LPARs are activated by PR/SM. • Once placed in real storage PR/SM will not move the LPARs’ storage. • PR/SM also allows that physical storage can be deallocated from one logical partition and reallocated to another while these LPARs are running. • VM (native) or native Linux do not support dynamic storage reconfiguration (changes to storage topology cannot be done while running images to prevent security breaches by reallocated memory in use).

10. 4. Channels and external devices in a LPAR • zSeries architecture allows multiple LPARs to share channels and the external devices connected to these channels. • It is also guaranteed that channels dedicated to one LPAR cannot be accessed by another LPAR, that access to control units and devices on shared channels can be restricted, and that non-shared channels will be reset before reallocation to other LPARs. • If a device that has to be accessed using a shared control unit and shared channels should be dedicated to one LPAR, this has to be defined in the I/O Configuration DataSet (IOCDS). • PR/SM ensures that no LPAR can access a device that is not defined to its partition, thus preventing the transfer of data between a LPAR and anything not explicitly allocated to it. • With several Linux systems running on different LPARs, it is possible to share channels and control units between the LPARs and the Linux systems.

11. 5. Networking in a LPAR environment • Network devices are simply another external device and have the same security considerations in the shared usage. Isolation and reconfiguration of these devices is the same as with other channels and control units. • OSA (Open System Adapter) ports can be shared between LPARs. • However, the network outside of the physical zSeries server must be given more care, and designed to ensure only authorized access to data or resources. • System administration tasks require secure network access to be granted separate from the normal Intranet and Internet. • Internal network communication between LPARs can be provided either by physical TCP/IP connections between the LPARs using the shared OSA port or virtual connections such as HiperSockets (more details in networking module). • Since these connections are not physically attached to the outside network, they are as secure as the LPARs themselves.

12. Considerations running Linux under VM • Similar security issues as with LPARs virtualization of resources. • What proof is there that guest systems are isolated (secure from access by other guests)? • How are z/VM resources and definitions protected against guest systems? • What is the risk if the resources of z/VM guest systems (memory, CPs) are reconfigured? • How secure are the different kinds of communication among Linux images (OSA, HiperSockets, Guest LAN, IUCV or VCTC)? • How can the dedicated and secured use of peripheral devices be assured if shared channels and control units are used?

13. 1. z/VM System Integrity Statement • The z/VM control program system integrity is the inability of any program running in a virtual machine not authorized by a z/VM control program mechanism under the customer’s control or a guest operating system mechanism under the customer’s control to: • Circumvent or disable the control program’s real or auxiliary storage protection. • Access a resource protected by RACF. Resources protected by RACF include virtual machines, minidisks, and terminals. • Access a control program password-protected resource. • Obtain control in real supervisor state or with privilege class authority or directory capabilities greater than those it was assigned. • Circumvent the system integrity of any guest operating system that itself has system integrity as the result of an operation by a z/VM control program facility. • Ultimately the level of system integrity achieved is dependant on the customer since the customer sets up and maintains the CP program and the guest systems.

14. 2. Definition/management of guest systems • z/VM transforms the principles of partitioning and enriches them with virtualization. • The Control Program (CP) of z/VM deals with the definition of the virtual guest systems and of the resources available to them, as well as the management of this environment. • One advantage of this setup is that OS failures that occur in virtual machines affect neither the z/VM OS running on the real processor nor other guests. • Privilege levels protect VM resources and definitions so that a guest can usually only manipulate their own environment. • Virtualization is transparent to guests. • RACF, a strategic security facility of z/VM, controls user access to the VM system and its virtual machines. • RACF also checks the authorization for the use of system resources like minidisks and data in spool files, and audits the use of them. • However, the RACF database cannot be shared with z/OS.

15. 3. Processors in a VM environment • CP defines and assigns logical processors to the guests (the virtual machines). • Logical processors are matched to the logical processors of an LPAR (or to the physical processors if VM is running native), which PR/SM maps to shared or dedicated physical processors. • With a zSeries server, a virtual machine can have up to 32 physical processors in the z990 (with up to 64 projected by the end of 2004) (CPs or IFLs). • If the guest’s OS can use multiple processors, it will dispatch its workload on its virtual processors as if it were running in a dedicated hardware environment. • CP handles dispatching the virtual processors on the real processors available to that virtual machine. • A real processor can either be dedicated to a virtual machine, or shared among virtual machines. • There is no security risk if the resources of VM guest systems are reconfigured, or if the virtual processors of different guest systems are dispatched to the same physical CPs or IFLs.

16. 4. Memory in a VM environment • Each virtual machine has its own defined virtual memory. • When a VM touches a page that is no longer in real storage, a page fault occurs and CP will bring the missing virtual page back into real storage. • Memory addresses used in a VM are virtual and have no meaning outside the VM. • CP also allows the sharing of virtual pages by a number of virtual machines. • Virtual disks (VDISK) can also be shared by several virtual machines—and data from shared minidisk (MDISK) caches can be copied to private virtual pages (useful with clones). • No security risk when the memory of VM guest systems is reconfigured, or if portions of the virtual memory of one guest are located by the CP in physical memory regions where the data of another guest resided earlier.

17. 5. Communication in a VM environment • Each OS running in its own virtual machine communicates with virtual devices. • VM minidisks are the virtual DASD devices used by virtual machines. • Minidisks (MDISK) can be shared or non-shared. • This is determined by the CP operator. • Minidisks links for guests can either be read-only or read-write. • Use of dedicated devices are not influenced by the VM OS. • Dedicated and secure use of peripheral devices such as VM minidisks is assured, even if shared channels and control units are used (see notes). • Interference between guests from a performance viewpoint can occur, but it is controlled by VM scheduling mechanisms so that the customer goals are met.

18. 6. Networking in a VM environment • Communication between a VM guest system and the outside world is established over the same physical hardware devices (as described with LPARs) with CP managing access to them. • VM will only manage devices defined as shared not dedicated. • Network design has the same considerations; it must be ensured that no unauthorized access to data or resources is possible. • For system administration tasks, a separate network with secure access to all guests is especially recommended. • Communication between a guest in a VM LPAR and another LPAR on the same zSeries server can be done while sharing the OSA port or HiperSockets. • Communication between two guests running in the same VM system (with VM running in an LPAR or on the native hardware) can be achieved using VCTC, IUCV or Guest LANs. • All these internal communication methods are completely secure in that an unauthorized third party cannot sniff since there are no physical lines.

19. z/VM TCP/IP stack • Runs in its own VM, and can be used as a router. • Eliminates the need to directly connect all Linux (or other guest OS images) to the outside world. • Eliminates the need to connect all Linux virtual servers to one another. • Has been enhanced to prevent some DoS attacks. • Smurf: Echo Request packets sent to IP broadcast or multicast addresses. • Fraggle: Echo Request packets sent to IP broadcast or multicast addresses. • Ping-of-Death: Echo Request packets that are too large. • SSL support is included.

20. Linux Security Recommendations • Disable unneeded services reducing security exposures. • Use the tcp wrapper daemon (tcpd) to protect and log whatever remaining services have been installed; it is an access control facility for internet services. • Can monitor incoming requests for telnet, finger, ftp, exec, rsh, rlogin, tftp, talk, comsat and other services that have a one-to-one mapping onto executable files. • Whenever a request for service arrives, the inetd daemon is tricked into running the tcpd program instead of the desired server. • tcpd logs the request and does some additional checks then runs the appropriate server program and goes away. • Use Secure Shell for remote access while protecting passwords. • SSH connections are encrypted and protected against IP or DNS spoofing. • The secure copy (scp) command can be used instead of FTP, and secure login (slogin) can be used instead of rlogin. *see notes • For additional security, remote login for root can be forbidden, limiting the root access to the Linux console (a VM session). Now both the VM and Linux passwords would need to be cracked. • Use shadow password utilities to avoid easy password cracks. • Stores passwords in /etc/shadow file which doesn’t have read access.

21. Security Recommendations Continued • Use the Pluggable Authentication Module (PAM) which provides a library of authentication modules. • Eliminates the need for each application to contain its own authentication code. • Monitor security news and alerts for new vulnerabilities or bugs in software running on the Linux server. • Sysadmin should frequently monitor the log files of the applications for any problems. • Use LDAP servers for authentication. • Limited database that stores relatively static information about objects (such as people, organizational units, printers, documents, etc.) as entries in a hierarchical structure. • LDAP provides a mechanism for clients to authenticate to a directory server, in order to get access to the information provided there. • OpenLDAP provides a directory service called slapd, which handles access control to, and management of, the databases containing the directory trees. It also contains the slurpd daemon, which helps slapd provide replicated service.

22. LDAP and RACF

23. Better Solution Allowing Multiple Hosts

24. Recommendations • Use firewall tool to protect your network. • Firewalls have a set of rules and procedures that tell them what to allow into the network and what to reject. • To control the traffic of TCP and UDP packets by using the IP firewall rules on the Linux kernel, IPTables should be used. • Protect against viruses and trojan horses. • Because of its software architecture (memory management and file/user permission design), Linux is not susceptible to most viruses. • But this does not mean that Linux is entirely safe from mischief or external threats, especially “Trojan horse” programs. • A very useful hardening tool is tripwire, which is able to detect and report file and directory modifications. This can help to detect Trojan horses and modified software left by hackers, for example for sniffing passwords. • It can be downloaded at http://www.tripwire.org/downloads/index.php. • Use tools for testing network security. • The scanlog daemon for example can recognize if someone is requesting more than a specific number of ports per second, which can indicate that someone is scanning the Linux server for insecure ports.

25. Packet filtering and Network Address Translation • As with separate servers, Linux for zSeries guests need to be protected when there is a connection to the outside world. • In a penguin colony you have the additional considerations created by having many different networks, for different customers, all sharing the same VM system. • Another unique consideration is that guests need to be protected from each other. • One feature that helps with this is the IPTables utility, which controls the Netfilter features of the Linux 2.4 kernel. • Netfilter provides very strong traffic filtering and translation capabilities, and is suitable for even some advanced firewalling roles inside your penguin colony. • The major part of netfilter/iptables is included in the standard Linux Kernel, but in order to do your runtime configuration of the firewalling subsystem, you will need the iptables userspace command, which can be downloaded from http://www.netfilter.org/downloads.html • In most cases, the vendor of your Linux distribution (i.e. Debian, RedHat, SUSE, Conectiva, Mandrake) will provide you with a pre-built version of this tool. • Go here for more documentation on netfilter: http://www.netfilter.org/documentation/

26. Network Address Translation (NAT) • Used to translate (between private and real IP addresses) the source or destination address of the IP packets traveling through the gateway. • It is a method of conserving IP addresses that can be used when you are implementing a Linux router/firewall for your connection between the Internet and a local LAN. • How it works • As packets leave the LAN, the router/firewall uses NAT to replace the source address of the originating computer with its source address. • The destination computer replies back to the router/firewall, and the destination address is modified to send it to the computer on a private LAN. • There are three basic types of NAT • SNAT (Source NAT): the source address of the first packet is modified. This is done after the routing, just before a packet leaves the router/firewall. • DNAT (Destination NAT): the destination address of the first packet is modified. DNAT is always done before routing, just after a packet enters the router/firewall. • Masquerading: this is a special form of SNAT used for dynamically assigned IP addresses. The source address of the interface where the packet is going out will is used.

27. Packet Filtering • A method of filtering data coming to a machine commonly used in firewall implementations. • Allows you to implement a firewall that will protect your computer from the outside world/Internet. • After the firewall is installed, every external computer that wants to talk to a computer on the internal network must ask the firewall for permission.

28. Linux packet filtering Protect your internal network that is connected to the Internet, from outside intruders. Perform Network Address Translation (NAT), which allows internally-connected computers without a registered Internet address to reach Internet resources. Filter the information going in or out of your internal network. Use your Linux server as a gateway between two different types of networks saving the cost of buying a router. Share your dial-up Internet connection with others.

29. Setting up packet filtering • Possible designs for networking infrastructures used for packet filtering implementations. • Always assume that the OSA card is configured to pass all traffic to a VM guest, not just the predefined addresses. • In the OSA card, only one IP address can be defined as the primary route (using OSA/SF Open System Adapter Support Facility), which means that this address will pass through all packets—not just the packet with the destination address for this IP address. • When the OSA card is defined to have the primary route, we always use a VM Linux guest as the entry point for all traffic. • In the following examples, we show a few different approaches for setting up an internal network for your VM Linux guests. • Single router/firewall with one server • Single router/firewall with DMZ on one server • Single router/firewall with more servers • Two-layer router/firewall implementation

30. Single router/firewall with one server Single Linux image which acts as a router and firewall for the Linux server on an internal network.

31. Single router/firewall with DMZ on one server • Uses a Demilitarized Zone (DMZ) to host our Web and mail server. • Because the DMZ is hosted on a separate interface the other server can be protected from external traffic.

32. Single router/firewall with more servers • Each server is connected to the router/firewall via an independent interface (this scenario is used when all servers belong to the same owner). • Allows you to ensure that only the correct packets are being forwarded to the servers, i.e. packet routing is controlled. • Also allows you to implement the DMZ for services that must be separated from the others.

33. Two-layer router/firewall implementation

34. Two-layer router/firewall implementation • 1st layer router/firewall is for the upfront Internet connection that serves the 2nd layer of routers/firewalls. • 2nd layer firewalls are used to isolate each local network from the others. • Provides an independent network for each small colony of Linux servers that’s connected to the outside world over its dedicated router/firewall. • Servers within the local network do not interfere with each other because each is connected to the router on its own interface. • If you need to implement a big colony of servers in the single-box solution use this approach.

35. IP Tables * Replaced ipchains starting with the 2.4 kernel

36. Cryptography on zSeries • zSeries servers offer specialized processors for cryptographic operations. • The use of these specialized cards saves the CPs and IFLs from having to perform the processor intensive task of cryptography. • The OS has to be able to recognize cryptographic instructions, pass them to the PCI-CC card to be executed, and return the result to the application. • As far as security is concerned the PCI-CC (Peripheral Component Interconnect Cryptographic Coprocessor)card can be shared and used with both z/OS and Linux workloads without any system integrity exposures. • Each operation is discrete and independent of those that precede or follow it. • Similar to the operation of a shared normal processor or channel, VM manages the queue of requests to ensure that a guest can see only its own request, thus the isolation is effective. • PCI-CC processor can also be dedicated to a Linux guest system in a virtual machine if necessary.

37. Usage of zSeries 900 PCI-CC card

38. What is LDAP? • The first attempt to provide an open directory service was the OSI service directory called X.500, the Directory Access Protocol (DAP). • DAP included a rich set of functions, but was also very complex making its applications difficult to implement. • The Lightweight Directory Access Protocol (LDAP) was designed to act as a gateway to X.500 directory servers. • LDAP at first made it easy to access the data, but it still required a full X.500 implementation. • LDAP was then further enhanced to act as a directory service itself, eliminating the need for X.500. • LDAP is an open Internet standard for providing directory services over the TCP/IP communication protocol. • It allows information to be managed and queried through a set of easy-to-use utilities and API.

39. Using LDAP • LDAP allows all user information to be kept in one place, and yet be accessed over the network. • As with a centralized /etc/passwd file, LDAP allows network administrators to store passwords, user names, preferences, telephone numbers and anything else, in one place. • This makes the life of the administrators easier by having a single instance of users on the network and thus maintaining users on many hosts from a single management point. • Accounts in the LDAP server can be created and deleted, and the changes made available immediately to LDAP clients. • On the server side, LDAP is used to provide clients with information about user accounts and user groups. • See Chapter 20 of Linux for IBM zSeries and S/390: Distributions for technical implementation and tips on installing

40. LDAP: slurpd • Replicating servers using slurpd • If user’s passwords are all verified by one server, this server becomes a single point of failure and potential performance bottleneck. • LDAP information can be replicated to a number of slave servers. • Clients can be divided among the servers, or the server addresses provided by some kind of round robin or workload balancing scheme. • All updates still need to be made to the master server. • If a slave server receives an update request, it refers the client to the master. • The master slapd writes all updates to a log file in LDIF format. • The log file is read by a daemon called slurpd, which then connects to the slave servers and makes the changes using normal LDAP functions. • Slurpd uses the same configuration file as slapd. • Preparing for replication • Slurpd must connect to the slave servers with an ID that has authority to update the database. • You can define the root in the slave’s slapd.conf file and use that user, or define a user to perform the updates.

41. LDAP data • What can be stored in the directory • The LDAP directory service model is based on entries. • An entry is a collection of attributes that has a name, called a distinguished name (DN). • The DN refers to the entry unambiguously. • Each of the entry's attributes has a type and one or more values. • The types are often character strings, like cn for common name, or mail for e-mail address. • A mail attribute might contain an e-mail address with an attribute value of zamir@us.ibm.com • How the information is arranged • Data is arranged in a hierarchical format that reflects political, geographic or organizational boundaries. • For example, entries representing countries appear at the top of the tree, below are entries representing states or national organizations, below them are entries for people, organizational units, printers, documents, etc. • LDAP allows control of which attributes are required and allowed in an entry through the use of a special attribute called objectClass. • The values of the objectClass attribute determine the attributes that can be specified in the entry.

42. Accessing LDAP data • How the information is referenced • An entry is referenced by its DN, which is constructed by taking the name of the entry itself (called the relative distinguished name, or RDN) and concatenating the names of its ancestor entries. • How the information is accessed • LDAP defines operations for managing information in the directory through a set of simple to use utilities and APIs. • These operations are provided for adding and deleting an entry from the directory and modifying an existing entry. • The LDAP search operation uses a search filter to allow a portion of the directory to be searched for entries that match some criteria. • Information can be requested from each entry that matches the criteria. • How information is protected • An Access Control List (ACL) provides a means to protect information stored in an LDAP directory. • Administrators use ACLs to restrict access to different portions of the directory, specific directory entries, or information within an entry. • Access control can be specified for individual users or groups.

43. LDAP directory tree

44. OpenLDAP overview • OpenLDAP is an open source implementation of LDAP. • OpenLDAP Web page is http://www.openldap.org/. • LDAP is a protocol used to access information stored in a directory. • The information in the directory is arranged in a hierarchical tree structure. • Each object is identified by a unique distinguished name, which identifies the object and its position in the tree, for example: uid=zamir,ou=People,dc=itso,dc=ibm,dc=com. • The structure and rules for the objects in the tree are defined by schema. • RFC2307 defines a schema for storing network information, including user and group details using LDAP. • OpenLDAP comes with this schema. • The OpenLDAP server consists of two daemons: slapd and slurpd. • The slapd (or standalone LDAP) provides a directory service. The directory can connect to a global LDAP directory service, or run a service. • The slurpd (or standalone replication) daemon helps slapd provide replicated service. It is responsible for distributing changes made to the master slapd database out to the various slapd replicas.

45. OpenLDAP • OpenLDAP is found in all distributions provided for zSeries. • OpenLDAP and PAM create a system in which userids and passwords can be centrally managed eliminating the need for each system to maintain its own database of passwords and userids or having the user remember each of their ids. • This method of storing user information using OpenLDAP and authenticating using pam_ldap provides a large amount of flexibility and security. • Allows the creation of a number of different types of users in the normal fashion on individual systems, and administered locally by root. • Global users with a network-wide home directory: • They were defined in the LDAP directory, and given an NFS-mounted home directory. • They can log on to any system and have access to their data. • Global users with local home directories: • They were defined in the LDAP directory, but with local home directories. • The systems are set up so that the first time a user logged on to a system the home directory was created if not pre-existent.

46. PAM and pam_ldap • PAM stands for Pluggable Authentication Module. • The PAM API provides a flexible authentication mechanism. • It allows different programs to be used to authenticate a user, without changing the application. • Rules are set up defining the methods to be used and the relationships between different methods. • PAM also allows other functions to be inserted into the authentication process, for example, creating a home directory. • PAM is included in standard Linux systems. • Modifying it means altering the configuration files to change the modules called and/or the order they are called in. • Pam_ldap provides a module that authenticates a user with an LDAP server. • It takes the userid and password entered by the user and attempts to use them to bind to the LDAP server. • If the LDAP server accepts the bind, the user is allowed to log in. • The password is stored on the LDAP server; all the client ever gets is a success/failure response. • By default these are transmitted unencrypted, which makes them vulnerable to packet sniffing-type attacks. For this reason implementing Transport Layer Security (TLS) is a good idea. • Additionally, to authenticate the server a certificate is generated to verify the identity of the server. • The clients are purposely separated from the servers so that not even the root userid on the clients can access or change the password information without actually knowing the password.

47. Configuring PAM • Once OpenLDAP is set up the system needs to be set up to use it for authentication. • This requires a change to the PAM configuration. • This may be set up very differently in different distributions. • PAM on SUSE is configured using files in the /etc/pam.d file. • Each program (login, ftp, passwd, su, etc) that needs to use PAM services has a configuration file. • The files have a list of module types and modules. • For each service the listed modules of the required type are called in order to determine the success or failure of the service.

48. LDAP diagram

49. Conclusion • Linux on zSeries can be run in native mode or LPAR mode. • In native mode Linux is the only operating system running on the hardware. With this mode physical resources must be dedicated while external resources can be shared. • When running Linux in LPAR mode both physical and external resources can be shared with the help of PR/SM which ensures each guest receives only what is intended for it while protecting other guests. • The five questions that must be answered to ensure the security of a Linux in LPAR mode environment are: • Is there an official certification that the processes of the PR/SM microcode are secure with zSeries architecture, and features like HiperSockets? • If CPs are shared between LPARs, is there any risk that one LPAR can influence the operations in another LPAR? • What is the risk if memory is reconfigured from one LPAR to another? • How can the dedicated and secured use of peripheral devices be assured, if shared channels and control units are used? • Should there be a secure administration access to Linux for zSeries systems, especially to those that are logically placed in DMZs?

50. Conclusion • The way processors are shared while maintaining the integrity of guests is that shared processors are given to multi LPARs each for a predetermined amount of time. Upon completing the task or receiving an interrupt it is given to another. When a processor is switched from use by one LPAR to another, its entire state is preserved and the new LPAR's state is restored. For the duration of its timeslice (period of allotted time), only this LPAR has access to the processor. Sharing can be achieved while maintaining the security and isolation of individual guests in a Linux for LPAR environment. • Memory is not shared between LPARs, but the total amount of memory installed is divided among the LPARs.