|
|
United States-English | |
|
|
 |
|
Software Distributor Administration Guide: HP-UX 11i v1, 11i v2, and 11i v3 > Chapter 9 SD-UX Security
RPC Authorization |
|
|
This section discusses how agents handle controller requests, local superuser authorization, depot registration, and daemon/agent security In SD-UX, objects are protected by ACLs. An ACL is a structure, attached to an object, that defines access permissions for multiple users and groups. It extends the concepts defined by the HP-UX file system mode bits in two ways: by allowing specification of the access rights of many individuals and groups instead of just one of each; and by protecting entire SD-UX objects, rather than individual files. Generally, a controller requests an agent to perform some operation on a object. SD-UX protects each host, depot, depot-product, and installation object (root) with an ACL. After a call is authenticated, the ACL manager is consulted for a caller’s access permissions to a protected object before allowing the action. SD-UX authorization uses ACLs to determine the RPC caller’s rights to access a particular SD-UX object in a particular way (i.e., read, write). An object’s ACL is searched for an entry that matches the caller. Once a matching entry is found, the permissions granted in that entry are compared to those required for the operation. If permissions required for the operation are all granted by the entry, access is authorized, and SD-UX proceeds with the requested operation. When a controller requests an agent to do an operation requiring the participation of another agent, the two agents must each grant access to the objects under their control before the operation can complete. For example, to install a product P from depot D to root R:
The ACL on swagentB neither knows of nor depends on user U. The ACL on root R acts to screen U; then (and only then) the product’s ACL acts to screen H. As a special case, the superuser always has full permissions on a local system. As a special case, SD-UX always allows the local superuser full access to all local objects regardless of ACL protections. This allows the local superuser to repair corrupted ACLs or to perform any other operations. SD-UX provides a form of delegation to control access to depot-resident products: both the host where the target agent is running and the user initiating the call must have read access. This form of delegation passes the caller credential information to the depot agent in the RPC options. This form of delegation works the same whether the agents are configured to use DCE or SD-UX Internal authentication. It is important to note that this delegation technique is provided to allow user-level access to depot-resident products. Because SD-UX stores its objects in the file system, someone could build a “Trojan Horse” file system image of a software depot. This could breech the security of any system that installed products from the false depot. To protect systems from such a situation, SD-UX requires that a depot be registered with SD-UX (either through swcopy or by using swreg) before software may be installed or copied from it. This check is always performed before granting access. Registration with swreg requires insert permission in the host’s ACL. As a special case, an unregistered depot may be used for local installation (i.e., the depot and destination root exist on the same system) if the initiator is the local superuser or has permission to register the depot (insert permission on the host). The administrator of a host system must ensure the integrity of new depots before registering them and ensure that only trustworthy users are granted permission to insert on the host.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 Printable version |
|
|
|
|
|
|||||||||||||||
|
|||||||||||||||
