Filter
Top Products
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 the hpssadm utility,
and must be specified on the hpssadm 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.
The keytab is interpreted on the host on which the Data Serverruns, 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.
As described 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
program to obtain the Data Server's private key and impersonate him. Such a program could then
collect the DCE passwords of your hpssadm users. This file must be readable only by root, stored
on a machine not accessible to untrusted users, and stored in an area not network-shared with any
other host.
The Data Server should be executed as root so that it can read its password file. It is not necessary
that the SSM System Manager be executed as root. The start_ssm script has been modified so that
if 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 and
System Manager under that userid. This is not recommended, but if the site chooses to do it, then
the Data Server's password file must be readable by this userid, and it should at least be protected
against access by any other user.
If the 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.
A second way an imposter could impersonate the Data Server is to override his binding in the RMI
registry. The RMI registry does not allow such access to processes from other hosts, but any process
on the 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
Data Server'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 the hpssadm 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
process which could modify the trusted certificate store could insert certificates for any entity, and
the hpssadm program would trust processes run by that entity.