Chapter 3 System Preparation
190 September 2002 HPSS Installation Guide
Release 4.5, Revision 2
The keytab file must be stored on each host from which the user will execute thehpssadm utility,
and must be specified on thehpssadm command line with the -k option:
hpssadm -k keytab_file_path_name
The keytab file should be owned by the user and protected so that it is readable only by the user.
Thekeytab is interpreted on the host on which the Data Server runs, not that on which the hpssadm
client utility runs. Therefore, it is not necessary to have DCE on the client machines.
3.8.7 Securing the Data Server and Client Host Machines
It is critical that the Data Server be executed on a secured machine in order to protect its keystore
password and in order to avoid RMI registry hijacking.
Asdescribed in Section 3.8.3: Configuring SSL on page 183, the Data Server must have access to the
password to its keystore file. If your site runs the Data Server in Low Security Mode, the Data
Server obtains this password from a cleartext file. Compromise of this file could allow an illicit
programto obtain the Data Server's private key and impersonate him. Such a program could then
collect the DCE passwords of yourhpssadm users. This file must be readable only by root, stored
ona machine not accessible to untrusted users, and stored in an area not network-shared with any
other host.
TheData Server should be executed as root so that it can read its password file. It is not necessary
thatthe SSM System Manager be executed as root. The start_ssm script has been modified so that
ifit is executed as root, it will start the Data Server as root but the System Manager as user "hpss".
If thestart_ssm script is executed under any other userid, it will start both the Data Server and
System Manager under that userid. This is not recommended, but if the site chooses to do it, then
theData Server's password file must be readable by this userid, and it should at least be protected
against access by any other user.
Ifthe site chooses to run in Normal Security Mode, in which the password is not stored on disk and
the administrator is prompted for it at Data Server startup, then the userid under which the Data
Server executes doesn't matter.
Asecond way an imposter could impersonate the Data Server is to override his binding in the RMI
registry.The RMI registry doesnot allow suchaccess to processes from other hosts, but any process
onthe local host can rebind any entry in the RMI registry and so pretend to be the Data Server. No
special privileges are required. Since an unprivileged program would still not have access to the
DataServer's private key, it ought not to be able to certify its identity to hpssadm clients nor induce
them to hand it their passwords, but it is still desirable that only trusted users have access to the
machine where the Data Server and its RMI registry are executing.
Each host from which thehpssadm utility is executed must be secure enough to insure that the
user's keytab file and trusted certificate store cannot be compromised. An illicit process which
gained access to the keytab file could gain the user's credentials anywhere in the DCE cell. A
processwhich could modify the trusted certificate store could insert certificates for any entity, and
thehpssadm program would trust processes run by that entity.