|
|
United States-English | |
|
|
 |
|
Software Distributor Administration Guide: HP-UX 11i v1, 11i v2, and 11i v3 > Chapter 9 SD-UX Security
SD-UX Internal Authentication |
|
|
This section discusses the following topics: SD-UX security does not replace DCE Security. It seeks to provide a usable protection scheme based on the assumption that there is no hostile, concerted effort by users to do damage. Much of the DCE security functionality used by SD-UX comes from the DCE Runtime Library that is included in SD-UX. This library provides DCE RPC capability and some of the DCE Security Services required to support ACLs. Without full DCE Security Services, it is impossible to reliably prove the identity of a user making an SD-UX RPC call; even if the source and destination of the RPC call is local. The RPC identifies only the network address of the calling client. A key to SD-UX security is determining which users are allowed to be involved in particular operations. In SD-UX internal authentication, your HP-UX uid, gid, and host name are used to establish your identity. The fact that the SD-UX controller runs with an effective uid of root (because the controller is a setuid-root program) does not affect your identity, which is obtained from your real uid. When you start an RPC (as an SD-UX controller), a structure describing your identity accompanies each call to an agent; the controller sends the user and group name of the person invoking the RPC, as well as the host name of the system on which it is running (in DCE, called the realm). This structure is called your credentials. Credentials consist of:
The user’s credentials are passed in the RPC parameters. The agent receiving the RPC uses this information to compare authentication credentials. SD-UX controller programs such as swinstall or swremove operate with the privileges of the user who invokes them. The agent ensures that the user has the required permissions on the object by looking at the object’s ACL. If permissions are not granted, the operation fails. A controller may be run by anyone on the system, but its actions are restricted (based on permissions granted in various object ACLs). SD-UX agents always verify that user-requested operations are authorized before performing them. 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:
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. 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.
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:
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.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 Printable version |
|
|
|
|
|
|||||||||||||||
|
|||||||||||||||
