Chapter 3 System Preparation190 September 2002 HPSS Installation GuideRelease 4.5, Revision 2The keytab file must be stored on each host from which the user will execute the hpssadm utility,and must be specified on the hpssadm command line with the -k option:hpssadm -k keytab_file_path_nameThe keytab file should be owned by the user and protected so that it is readable only by the user.The keytab is interpreted on the host on which the Data Server runs, not that on which the hpssadmclient utility runs. Therefore, it is not necessary to have DCE on the client machines.3.8.7 Securing the Data Server and Client Host MachinesIt is critical that the Data Server be executed on a secured machine in order to protect its keystorepassword and in order to avoid RMI registry hijacking.As described in Section 3.8.3: Configuring SSL on page 183, the Data Server must have access to thepassword to its keystore file. If your site runs the Data Server in Low Security Mode, the DataServer obtains this password from a cleartext file. Compromise of this file could allow an illicitprogram to obtain the Data Server's private key and impersonate him. Such a program could thencollect the DCE passwords of your hpssadm users. This file must be readable only by root, storedon a machine not accessible to untrusted users, and stored in an area not network-shared with anyother host.The Data Server should be executed as root so that it can read its password file. It is not necessarythat the SSM System Manager be executed as root. The start_ssm script has been modified so thatif it is executed as root, it will start the Data Server as root but the System Manager as user "hpss".If the start_ssm script is executed under any other userid, it will start both the Data Server andSystem Manager under that userid. This is not recommended, but if the site chooses to do it, thenthe Data Server's password file must be readable by this userid, and it should at least be protectedagainst access by any other user.If the site chooses to run in Normal Security Mode, in which the password is not stored on disk andthe administrator is prompted for it at Data Server startup, then the userid under which the DataServer executes doesn't matter.A second way an imposter could impersonate the Data Server is to override his binding in the RMIregistry. The RMI registry does not allow such access to processes from other hosts, but any processon the local host can rebind any entry in the RMI registry and so pretend to be the Data Server. Nospecial privileges are required. Since an unprivileged program would still not have access to theData Server's private key, it ought not to be able to certify its identity to hpssadm clients nor inducethem to hand it their passwords, but it is still desirable that only trusted users have access to themachine where the Data Server and its RMI registry are executing.Each host from which the hpssadm utility is executed must be secure enough to insure that theuser's keytab file and trusted certificate store cannot be compromised. An illicit process whichgained access to the keytab file could gain the user's credentials anywhere in the DCE cell. Aprocess which could modify the trusted certificate store could insert certificates for any entity, andthe hpssadm program would trust processes run by that entity.
