Basically security is provided on the SP system, not by some independent means, but by having a comprehensive security policy enforced by a combination of the following:
With respect to security, the SP system is basically a cluster of |IBM 
pSeries or RS/6000 nodes connected on one or more LANs, with the control workstation serving
as a central point to monitor and control the system. The SP system is
exposed to the same security threats as any other cluster of workstations
connected to a LAN. The control workstation, as the single point of
control, is of particular concern. If security is compromised there,
the entire system is effected.
In today's distributed environments, many autonomous computing systems are interacting. They are often connected through an unreliable (in terms of security) network, which is used for remote login or command execution, remote data access, and for remote management. Each of these computers might have its own administrator and its own user database and file space. The services they offer are often based on the client-server model. The SP system participates in such an environment.
Distributed client-server environments represent a way to quickly and transparently deliver information to users from various sources and locations. This technology can help companies reduce cost and time as well as improve quality and customer satisfaction. The client-server model implies cooperative and distributed processing and relies on a message-based communication between a requester (or client) that asks for a specific service and a responder (or a server) that provides the information. The message exchange can be synchronous or asynchronous.
The most basic form of client-server computing has only two pieces: a client process and a server process connected through a network. The server process is the provider of services and the client is the consumer or requester of services. Clients usually manage the user interface portion of the application, while server programs generally receive requests from client programs, execute the specified action, and dispatch the response to the clients. The client software component requests a service on behalf of the user, like a login request, access to a remote file, or an action to be performed on an object. The server, which often runs on a different machine, processes that request after checking the client's identity and permissions, in other words, after authenticating the client.
Administering an SP system from a single point of control requires the use of administrative applications that are based upon the client-server programming model. Typically, a client-side command line or graphical user interface is used to perform an administrative task on one or more network-attached nodes or workstations, in parallel or serially. Where privileged applications such as these communicate across networks, security can be compromised unless a reliable means is used to restrict access to authorized users. Accomplishing this authorization first requires authentication, which is the validation of the identities of client and server. Authentication is also the foundation for providing other security features such as accountability, discretionary access controls, and least privilege.
An SP system implementation, for example, can consist of SP nodes with internet connections, a control workstation, and connections to other clustered workstations. Any of these system elements can be vulnerable to a security compromise. All networked services, as well as clients who may need to provide sensitive data to services, must be able to restrict access to those services according to a meaningful security policy. Such access restrictions can be successful only by the reliable authentication of the identities of clients and servers.
There are primarily two facets of security that an administrator addresses:
In order to address these two facets of security, you need to understand the different levels of security.
The first level of security is identifying the individual or client attempting to access your system. The second level involves authenticating the individual, usually by using an ID and password. The third level of security involves authorizing an individual or client to access certain parts of the system for which they have authorization. Each of these levels involve information having to pass certain checks involving criteria that can differ with the authentication method in effect:
Apart from the fact that most security exposures are still caused by poorly chosen passwords, the insecure network introduces several new security threats. Both partners of a client-server connection might be impersonated, that is, another party might pretend to be either the client (user) or the server. Connections over the network can be easily monitored and unencrypted data can be stored and reused. This includes capturing and replaying of user passwords or other credentials, which are sent during the setup of such client-server connections.
A common way to prevent impersonation and ensure the integrity of the data that is transferred between client and server is to set up a trusted third party system, which provides authentication services and optionally, encrypts all the communications to allow secure communication over the physically insecure network. A popular system which serves this task is Kerberos, an authentication method designed and developed by the Massachusetts Institute of Technology (MIT).
|With PSSP 3.4, you have the option to choose which security services are to be used on your SP system:
For each SP system partition, you can choose to use the new PSSP support of DCE, the continuing PSSP support of Kerberos V4, or the standard AIX authentication service. |If you are running with restricted root access and a secure remote |command process enabled, you can choose none for the AIX |Authorization for Remote Command Methods option. Otherwise, you must use at least one authentication method for remote commands. You can choose not to use authentication for SP trusted services if you consider your environment secure enough anyway. You can specify the following:
Selecting the compatibility authentication method means that each SP trusted service is free to operate as it did before PSSP 3.2. Services which used ACL, Kerberos V4, and AIX authentication, or no authentication will continue doing that.
When determining which authentication method to use for remote commands, AIX examines the order of precedence set by the AIX chauthent command. This order determines which authentication method is used when the remote commands are issued on the workstation. This means that if the first method fails authorization, the second method is tried, and so on. The order of precedence, defined as being from the highest level of security to the lowest level of security, is Kerberos V5, Kerberos V4, then Standard AIX.
The PSSP software includes two types of administrative programs that benefit from these security features:
Security is achieved through PSSP services being trusted to correctly enforce the security policies of the SP system in cooperation with the enabled authentication methods. Each service which provides access to the system or to any operation or information in the system is responsible for enforcing the security policy as it applies to the objects for which it is responsible. Such services are called SP trusted services. They each have a service principal for DCE and a key with an encryption mechanism.
Each SP trusted service defines and enforces a discretionary access control policy: PSSP does not support mandatory access controls or integrity controls. A discretionary access control policy is one that allows the owner of an object (or some appropriately authorized user) to determine the type of access to the object that may be granted to other users.
Trusted services authenticate clients and each other, based on the authentication methods enabled by the administrator, according to the following convention:
The PSSP components and the SP trusted services enforce security as applicable to their environment. While the environment is common to most SP services and allows them to enforce security in a common manner, some PSSP components or SP trusted services might have an environment that causes them to enforce security by different means. For instance, LoadLeveler and the RSCT software can run on systems without PSSP, so they use different means to enforce security, but they are still SP trusted services.
Most interaction with SP trusted services is internal but often through user interfaces such as SP Perspectives, SMIT, or commands. As a result, there are cases when individual users need to be directly authorized to use a service, while in other cases individual users need only be authorized to use the PSSP component which uses the SP trusted services.
Table 1 lists the SP trusted service and the type of authentication
it does depending on the authentication enabled and the PSSP release
level.
| SP trusted service | Authentication Methods | |
|---|---|---|
| PSSP 3.2 | Pre-PSSP 3.2 | |
| Communication Subsystem (CSS) | Client is root | Client is root |
| Dynamic Probe Class Library | DCE and compatibility | AIX user ID and group ID with CDMF encryption |
| Event Management | Uses RMS for service communication, DCE or compatibility for clients | Uses RMS for service communication, none for clients |
| General Parallel File System | DCE and compatibility | None |
| Group Services | Uses RMS and client is root or member of AIX group hagsuser | Uses RMS and client is root or member of AIX group hagsuser |
| Hardware Monitor - hardmon | DCE ACL and compatibility | Kerberos V4 ACL, or none but client is root |
| LoadLeveler | DCE or compatibility, plus rsh authority and connectivity to LoadL scheduler | connectivity to LoadL, CDMF encryption, AFS credentials or DCE credentials, valid ID on node. |
| Parallel Environment | DCE and compatibility | rsh/rcp authority on node |
| Problem Management | DCE and compatibility | Kerberos V4 principal or AIX user ID with sysctl authority to initiate processes |
| Reliable Message Service (RMS) for UDP/IP messages | Authentication provided by topology services | Authentication provided by topology services |
| Switch Table Services | DCE and compatibility | Client is root |
| Sysctl | DCE ACL and compatibility | Kerberos V4 ACL, or none but client in sysctl ACL |
| System Data Repository | None for reads, otherwise DCE and compatibility | None for reads, otherwise client is root |
| Topology Services | DCE key file and compatibility | None but client is root |
|The SP trusted services can use two authentication methods to authenticate |their clients: DCE and compat (or k4). The authentication method |chosen depends on the node's authentication setup. You can use the |lsauthent command to display the current setup of a node. |When no authentication method is set up, the trusted services use what is |called the none/std method. This really is not an |authentication method. It merely indicates the fact that no |authentication method has been set on the node for SP trusted services.
|Authorization of clients to request services is important to sysctl, a |trusted service, and to the overall system security, because sysctl runs as |root on the host. When an authentication method is set on the node, the |sysctl process attempts to authenticate its clients and, if authentication |fails, it rejects the request. If authentication is successful, then |ACLs are used to authorize clients. If the authentication method is |DCE, then the DCE native ACL support is used. When the authentication |method is compat (or k4), the sysctl native ACL files are being used. |When the none/std method is used, sysctl behaves in a special manner. |Although none/std implies that no authentication method is set on the node, |sysctl authenticates and authorizes clients using their AIX identity. |From a security standpoint, all clients should be considered unauthenticated |by the sysctl because an AIX identity is not a trusted identity in a networked |environment without the support of a strong security mechanism (by means of |integrated login).
|Sysctl ACLs support two types of entries that implement the authorization |of clients: _principal and _other_unauth. The _principal entry |has an identity of form user_name@host_name, |wherehost_name is the fully qualified host name of the node. |The _other_unauth entry does not have any identity. The authorization |policy can be described as follows: when the identity of the client can |be matched with one _principal entry's identity, then access is |permitted. If no match can be found, sysctl looks for the _other_unauth |entry. If not found, the client is denied access. If found, the |client is allowed permission. The _other_unauth entry is misleading in |the way it is named because it is being used only for none/std. When an |authentication method (for this discussion, compat) is set on the node and the |client fails authentication, access is denied outright, regardless of the |_other_unauth entry being present in the sysctl ACL file or not.
|There are several implications of this discussion regarding the security of |the system. We do not suggest that customers run their system without |an authentication method being set. However, there are cases when a |system administrator does not want to deal with the complexity of setting the |authentication method and the authorization policy during an initial install |and setup of the system. Also, the system administrator might choose to |use none/std on a system that is completely disconnected from the rest of the |(networked) world. To be able to run properly in such an environment, |the system administrator must modify sysctl ACL file to reflect the new |reality.
|The following ACL files are affected: |
|The changes can be done in the same manner for all the above ACL |files. For the files on the control workstation, you can manually add |_principal entries with the identity root@host_name for each node |in the system or you can add the _other_unauth entry. For the ACL files |that must be updated on all the nodes, you can do the same as in the case of |the control workstation files. Then you can do remote copies of the |files to the relevant nodes.
|The SP system supports using the AIX authenticated remote commands |(rsh, rcp, rlogin), plus the ftp and telnet |commands for system management. Those commands are available for |general use and support multiple authentication methods. Several SP |system components rely on the ability to use the rsh command to |issue remote commands as the root user from a node to be run on the |control workstation or from the control workstation to be run on nodes. |Likewise, several components use the rcp command to copy files |between the control workstation and nodes. In order to provide this |capability, PSSP has effectively defined one root user across the entire |SP system. Gaining access as root on any node in the SP system |implies that you can gain access as root on the control workstation and all |other nodes in the SP system.
|When, for instance, the SP is used as a server consolidation system, |this single root user might not be desirable. As of PSSP 3.2, |the restricted root access option is available to limit the use of |rsh and rcp within PSSP software. It restricts |the PSSP software from automatically using rsh and rcp |commands as root user from a node. When restricted root access is |active, any such actions can only be run from the control workstation or from |nodes explicitly configured to authorize them. It restricts root |rsh and rcp authorizations from the nodes to the control |workstation, but permits control workstation to node rsh and |rcp access.
|At the time restricted root access is activated, the SP and the root owned |remote command authorizations are reconfigured such that: |
|When PSSP software on the nodes needs to copy or access files or execute |commands on other nodes or the control workstation, sysctl is used to perform |the task from the control workstation. The restrictions imposed by |using restricted root access have implications for the functionality of some |PSSP and non-PSSP components as well as system management.
|Restricted root access can be activated under all the security |configurations supported by PSSP 3.2 or later. However, |restricted root access is most relevant when you use a secure remote command |process and with PSSP security methods dce, |dce:compat, and compat. Otherwise, |restricted root access under the minimal security state none/std is |of little value.
|For the remainder of this section, all references to access control lists |(ACLs) apply to root owned sysctl and AIX remote command ACLs because they |apply to the different PSSP security configurations.
|Restricted root access can be enabled by setting a site environment |attribute in the SDR. Because the SDR in non-DCE environments can be |changed by root automatically, the SP_Restricted class was created |with the restrict_root_rcmd attribute. It can only be |changed by user root on the control workstation. The default |value is false.
|You can change the attribute by using the Site |environment SMIT panel or by using the spsitenv |command. When changed, the authorization files on the control |workstation and the nodes are immediately updated. All commands that |require rsh or rcp access check the attribute each time |access is required. They automatically use the sysctl method when |restricted root access is enabled.
|AIX remote command authorization files for root on the nodes and the |control workstation are generated and updated by the updauthfiles |script. This script is run at various times including when the |restricted root access state is changed, when the security settings on the |system are modified, and when a node is installed or booted.
|When restricted root access is enabled, |updauthfiles removes all SP-generated entries in the remote command |authorization files and adds the following entries, which are dependent on the |authentication method set for auth_root_rcmd: |
|Any manual changes previously made to these files are not removed |automatically. Also, before PSSP 3.2, the |/.klogin entries generated by the SP were not saved in a |separate file. If you have migrated your system from a previous release |of PSSP, there might be SP-generated entries in your |/.klogin file that are no longer recognized. It is a |good idea to check the content of all root remote command authorization files |after activating restricted root access.
|The sysctl facility is an authenticated client-server system for running |commands and TCL scripts remotely and in parallel. The sysctl server |daemon sysctld processes all sysctl client requests for the node on which it |runs. There is a sysctld daemon running on each node of the SP system |as well as on the control workstation.
|By default, the /etc/sysctl.conf configuration file is |read and interpreted each time the sysctl server is started or |restarted. This file contains the definitions of the commands that can |be executed by sysctl. Additional sysctl commands are supplied with |PSSP to enable restricted root access. Since the contents of the |/etc/sysctl.conf file on the control workstation are |different from the one on the nodes, the control workstation version should |not be included in any file distribution scheme.
|Access to the new sysctl commands is provided through a set of sysctl |access control list (ACL) files shipped with PSSP. For |compat mode, these ACLs are installed in the /etc |directory and contain a Kerberos V4 entry for the global SP principal |root.SPbgAdm. For DCE mode, the sysctl daemon |initializes new DCE ACL objects relating to the new sysctl commands with |entries for the PSSP DCE principal, ssp/.../spbgroot, which |allow the principal to access the new sysctl commands. (For minimal |mode, none/std, with restricted root access enabled, sysctl ACL entries must |be manually updated to allow the new sysctl commands to be executed. |However, this is not a suggested security configuration under which to enable |restricted root access.
|For sysctl to function correctly with restricted root access enabled, it is |important that the sysctl daemon use the same default TCP/IP port number on |all nodes and on the control workstation.
|Overall, sysctl becomes a critical part of the SP environment when |operating with restricted root access.
|Restricted root access is a feature that creates new functionality within |PSSP and fundamentally changes authorization methods. Obviously, this |has consequences for some PSSP components and related licensed programs that |are used in an SP environment.
|See the respective licensed program publications for information about |running them under various PSSP security configurations.
|When restricted root access is enabled, it can only be used in a system |with all nodes running PSSP 3.2 or later. If you are restricting |root access in order to use a secure remote command process, the control |workstation must have PSSP 3.4 and all the nodes must have PSSP |3.2 or later. At activation time, the spsitenv |command checks whether all nodes are at a correct level. If there are |nodes at a level earlier than PSSP 3.2, restricted root access cannot |be activated. That also affects the ability to activate a secure remote |command process.
|During configuration and run time the Virtual Shared Disk component of PSSP |(VSD) and the GPFS licensed program rely on existing combinations of |rsh and sysctl commands and nested sysctl |calls to access information on the control workstation as well as on other |nodes (node-to-node). The existing architecture relies on the existence |of a common PSSP root identity that can be authorized successfully under |rsh and sysctl ACLs. When restricted root access |is enabled, the common PSSP root access required by VSD and GPFS is |disabled. When attempting to activate restricted root access, if VSD |adapters are defined or if GPFS is installed on the control workstation, the |activation will fail.
|The HACMP licensed program can use Kerberos V4 as an authentication and |authorization method that requires additional principals and interfaces |defined in the Kerberos V4 database. When restricted root access is not |enabled, adding additional principals to the Kerberos V4 database can be done |manually or by running the cl_setup_kerberos script. This |script is run from an HACMP node and does the following: |
|When restricted root access is enabled, the actions performed by |cl_setup_kerberos are no longer possible due to the HACMP |rsh and rcp requirements from a node to the control |workstation. Also, the HACMP nodes can no longer use rsh and |rcp to synchronize the HACMP ODM, given that the remote command |authorization files on the control workstation (and other nodes) will no |longer have common root authorization from node-to-node or node-to-control |workstation. These authorizations will have to be added manually to the |appropriate root-level remote command authorization files.
|The synchronization capability can be restored by editing the |/.klogin files on the HACMP nodes, for a compat/k4 enabled |security mode, explicitly allowing both systems to have root access to each |other. The restricted root access function will not interfere with |custom settings.
|Updating the Kerberos V4 database using the cl_setup_kerberos script |requires root access to the control workstation, which is exactly what |restricted root access was designed to eliminate. Manual updating of |the Kerberos V4 database is the most secure way to ensure that the database is |updated, but this is a complex and error-prone method. A workaround is |to temporarily add the HACMP nodes to the /.klogin file on the control |workstation, for a compat/k4 enabled security mode, run the cl_setup_kerberos |script, and then remove the authorizations immediately afterwards.
|See the HACMP documentation for details on running with HACMP under various |PSSP security configurations.
|When using the HACWS component of PSSP, there are no problems in the |authentication of both systems on the nodes. However, you have to copy |the authorization files, /.rhosts or |/.klogin, to the backup control workstation. Also, it |is important that you activate restricted root access from the active primary |control workstation, since it is the Kerberos V4 Master.
|There are several restrictions and limitations for HACWS when running with |DCE security mode enabled and in other situations that apply when running with |restricted root access enabled as well. See the 'Limitations and |Restrictions' section in Chapter 4 of the book IBM RS/6000 SP: |Planning Volume 2, Control Workstation and Software Environment.
|Currently, only one boot-install server (the control workstation) is |supported when restricted root access is activated. Since boot-install |servers are NIM Masters, they need to have remote command (rsh) |access to the control workstation when changing SP nodes. Boot-install |servers also need rsh capability on their client nodes during |installation time. At run time, remote command authorization on the |client nodes is only needed when a software or patch update is |required.
|However, depending on the size of your system and network loads, it might |not be possible to have a single boot-install server. Though PSSP does |not automatically create the correct entries in the authorization files to |allow the remote commands to function, you can create the |authorizations.
|To use multiple boot-install servers, you can manually establish the |correct authorizations on your system: |
|/usr/lpp/ssp/sysctl/bin/install.cmds |/usr/lpp/ssp/sysctl/bin/switch.cmds |
|/usr/lpp/ssp/samples/sysctl/firstboot.cmds
|With restricted root access, the following switch management commands can |only be run from the control workstation: |
|With restricted root access, certain system management commands should only |be run from the control workstation. If run from a node, authorization |failures might prevent successful completion. The following commands |should only be run from the control workstation: |
|Using restricted root access will not, in itself, make your SP system more |secure. The fact that PSSP does not automatically authorize root to use |rsh and rcp commands from a node and gain default access |on other nodes within the SP does not prevent root from logging in to another |node using the telnet command.
|Even if you disable the ability for root to remotely log in to nodes and |the control workstation, root can still use the su command to |switch to another user and then exploit that user's remote command or |other AIX and PSSP remote command capability to access other nodes or the |control workstation.
|You will have to adapt your user management for root to fit into the new |access policy.
|PSSP 3.4 gives you the ability to have the PSSP software use |a secure remote command process in place of the AIX rsh |and rcp commands. You can acquire, install, and configure |any secure remote command software of your choice that conforms to the IETF |Secure Shell protocol. With restricted root access and a secure remote |command process enabled, the PSSP software has no dependency to internally |issue rsh and rcp commands as a root user from the |control workstation to nodes, from nodes to nodes, nor from nodes to the |control workstation.
|You must have PSSP 3.4 and the secure remote command software |running on the control workstation, PSSP 3.2 or later running on the |nodes, and enable the restricted root access option before or when you enable |the secure remote command process. Then you can proceed to the rest of |the PSSP security configuration.
|PSSP 3.4 supports three environment variables to let you pick |whether you want the PSSP software to use AIX rsh and |rcp remote commands or a secure remote command process for parallel |remote commands like dsh, pcp, and others. The following are the |environment variables and how to use them: |
|Like the restricted root access option, a secure remote command process |can also be enabled by using the SP Site environment SMIT menu or |the spsitenv command. It is extremely important to keep |these environment variables consistent and set to the remote command process |you want to use.
|After you enable a secure remote command process, if all the nodes in the |SP system partition are running PSSP 3.4, you have the ability to set |the AIX authorization method for remote commands to none |in that partition. If you do that PSSP does not automatically grant |authorization for root to issue rsh and rcp commands |from a node or from the control workstation. |If none is set for all partitions, the |updauthfile script removes all SP-generated entries in the remote |command authorization files.
|For preparing to install and configure PSSP security and secure remote |command software, and for limitations see the book IBM RS/6000 SP: |Planning Volume 2, Control Workstation and Software Environment . |To update the site environment security attributes, see the book |PSSP: Installation and Migration Guide.
|Suggested reading for a secure remote command environment is SSH, The |Secure Shell, O'Reilly. |