Software Distributor (SD-UX) Administration Guide HP-UX 11i v1, 11i v2, and 11i v3 (762797-001, March 2014)

Agents Run with the System’s Identity
The SD-UX agents and daemons run with the privileges of a superuser; but they also have the
special identity of the host system on which they are executing. When a target agent makes an
RPC call to a source agent, two sets of credentials are passed with the call:
• those of the agent’s system
• those of the user running the controller on whose behalf the target agent runs
While local superuser privilege is necessary for the agent to do required local file system operations
such as file creation and deletion, ACL management, etc., this level of permission is neither required
nor desired for DCE RPC operations with other SD-UX processes.
When SD-UX agents perform RPCs, they assume the identity of the system on which they run, rather
than that of a particular user.
Security Between Hosts: The Shared Secrets File
In addition to the caller’s credentials, other evidence of trustworthiness is also sent in the RPC. The
SD-UX agent checks this evidence before accepting the caller credentials. This evidence consists
of passing the encryption of a secret password. The password is read from the shared secrets file.
This file is located on systems in /var/adm/sw/security/secrets.
NOTE: The SD-UX Secret must be the same on both the target system and the controller.
The agent compares this encrypted secret to the encryption of a local secret it shares with the
controller’s host. If the secrets do not match, the call is not authenticated and it fails.
Secrets are stored by host name in the secrets file and are used to establish trust between two
systems. The controller selects a secret in the file that corresponds with the host name of the system
on which it is running. The agent, upon receipt of an RPC from the controller, looks up a secret
associated with the controller’s host.
For example, if the controller is running on alma.fc.hp.com and makes a request of an agent
running on lehi.fc.hp.com, each of the two processes will look up the secret associated with
alma.fc.hp.com (the controller’s host) from their respective secrets file.
Here is an example of the format of the shared secrets file:
default quicksilver
lehi.fc.hp.com s28ckjd9
alma.fc.hp.com 32hwt
newdist.fc.hp.com zztop
noway.fc.hp.com daisey
The first column represents the controller’s host name and the second column represents the
controller’s secret.
There is also a provision for a default secret (quicksilver in the example above), to be used
when no system name match is found in the secrets file. The entry is identified with the default
pseudo-host name. This entry allows open SD-UX interconnect between hosts sharing the same
default entry. SD-UX is shipped with the secret -sdu- that should be changed for your site.
When you change a host’s secret, make sure you change it in the secrets files of all hosts with
which you work. The secrets file may be produced in a single site, then copies distributed to all
participating hosts.
NOTE: The secrets discussed here does not grant any access to SD-UX objects, but do allow a
host to participate in SD-UX operations.
RPC Authorization
This section discusses how agents handle controller requests, local superuser authorization, depot
registration, and daemon/agent security
RPC Authorization 159