IBM Books

Administration Guide


Providing security

Security is provided by the operating system - only root can run functions or modify system data. Flexibility in the degree of security required by a specific environment is provided by remote shells that conform to the IETF (Internet Engineering Task Force) secure remote command. Remote shells can be specified using the dsh command. See the dsh man page for details on how to specify the remote shell of your choice by using the DSH_REMOTE_CMD environment variable.

dsh security

The distributed shell dsh command uses either the underlying rsh security protocol, or a secure remote command protocol. By default, rsh is used. It is the system administrator's responsibility to configure and enable remote shell access to other systems, and to fulfill the particular security obligations of a specified environment.

Note:
Be aware that the dsh command does not provide the set up for a specific security configuration. The system administrator is responsible for fulfilling the particular security obligations of a specified security environment. At a minimum, you can configure rsh with the /root/.rhosts file on the nodes. A more secure environment might have Kerberos configured, or might be using some type of shell that conforms to the IETF (Internet Engineering Task Force) secure remote command protocol.

Note that if you wish to use a secure remote command protocol, Red Hat OpenSSH, which is installed with Linux Red Hat 7.1 and 7.2 is required.

For more information about thedsh and dshbak commands, see the man pages or CSM Commands.

Specifying a remote security protocol

As a system administrator, you need to decide which remote command protocol you want to use for remote communication; rsh or a secure remote command. You can do this with the $DSH_REMOTE_CMD environment variable, by setting it to the full pathname of your rsh or secure remote command (for example, /usr/bin/secureremote). You can also use the -r (remote shell path) option of the cfmupdatenode command. When the cfmupdatenode command is run, it first checks for the value of the -r option. If the option has not been not set, it checks for the value of the $DSH_REMOTE_CMD environment variable. If the environment variable has also not been set, the cfmupdatenode command defaults to using rsh.

For more information about using the cfmupdatenode command, see the man page or CSM Commands.

If you use rsh, make sure each node has a $HOME/.rhosts directory that contains the management server host name. Adding rsh to the end of /etc/securetty on each node allows root to rsh into the node. Also, make sure the rsh daemon is running on each node. Use the chkconfig - -list command to check it, or use the chkconfig rsh on command to turn on rsh.

RSCT security

CSM uses the security function of RSCT to ensure that the software components in your cluster can properly authenticate the identity of the peers, clients and subcomponents they interact with. Since it is possible for one of these peers, clients, or subcomponents to imitate another, it is important that the components of your cluster can verify that the parties they interact with are who they say they are. Instead of merely requiring each party to verify the identity of the other when a connection is established, RSCT security uses a message authentication process to do this.

RSCT message authentication

The authentication mechanism used by RSCT security involves the sending and receiving components in your cluster exchanging message keys. Each message that is sent between the parties is signed by the sender, and the signature is then verified by the receiver. The information needed to verify the signature of a message is contained in a key. Each node has a private key, which it uses to encode the messages that it sends to other nodes. A public key is derived from the private key and distributed to the other nodes of the cluster. The receiving node then uses the public key to decode the messages from the sender. For a more detailed description of message keys and RSCT security's authentication services, refer to IBM RSCT for Linux: Guide and Reference.

When configuring a cluster of nodes, by default, the necessary key exchanges between cluster nodes is automatically carried out by CSM. The public key is copied from each of the managed nodes to the management server, and the management server's public key is also copied to each of the managed nodes. If you feel that your system is not secure enough to prevent address and identity spoofing, you need to transfer the public keys between the management server and the nodes manually. For information on how to do this, refer to IBM RSCT for Linux: Guide and Reference.

RSCT authorization

CSM implements authorization using the access control list (ACL) file. You can create a new ACL file to apply access control to resource classes, or you can use the default ACL file, which is provided with RSCT. A sample ACL file is provided in /usr/sbin/rsct/cfg/ctrmc.acls.

The ACL file is in stanza format. Each stanza begins with the stanza name, which is the name of a resource class. Each line of the stanza contains a user identifier, an object type, and an optional set of permissions. A stanza line indicates that the user at the host has the permissions to access the resource class or resource instances (or both) for the resource class named by the stanza.

For any command issued against a resource class or its instances, the RMC subsystem examines the lines of the stanza matching the specified class in the order specified in the ACL file. The first line that contains 1) an identifier that matches the user issuing the command and 2) an object type that matches the objects specified by the command is the line used to determine access permissions.

For more detailed information about authorization and the ACL file, see the IBM RSCT for Linux: Guide and Reference.


[ Top of Page | Previous Page | Next Page | Table of Contents | Index ]