Jump to content United States-English
HP.com Home Products and Services Support and Drivers Solutions How to Buy
» Contact HP
More options
HP.com home
Software Distributor Administration Guide: HP-UX 11i v1, 11i v2, and 11i v3 > Chapter 9 SD-UX Security

Security Use Models

» 

Technical documentation

Complete book in PDF
» Feedback
Content starts here

 » Table of Contents

 » Glossary

 » Index

The use models below use the swadm group that is provided in the default host ACLs, which are installed at SD-UX install-time. This group is not a part of the default HP-UX configuration, but can be easily added. First, add the swadm group and the appropriate group members by using the HP-UX System Administration Manager product. Next, provide the /etc/logingroup link to /etc/group to activate HP-UX supplementary groups.

NOTE: /etc/logingroup is an HP-UX utility to support both SVR2/3 and BSD group semantics selectively. When /etc/logingroup is linked to /etc/group, HP-UX gives BSD (and SVR4) semantics.

If the file /etc/logingroup does not exist on systems targeted as SD-UX Controllers, execute the following command (as superuser) on each appropriate system:

ln -s /etc/group /etc/logingroup

Security in Remote Distributions

A common use of SD-UX remote operations capabilities is for a software administrator to push software from a local depot out to numerous remote targets.

You can set up of this kind of configuration:

  1. Establish the group swadm on the controller host as described above.

  2. Edit the three host ACLs on each target system. If you used the suggested setup discussed in “Setting Up Remote Operations” to install the agents on the target systems, you may edit the three host ACLs on the Targets as superuser on the system from which you performed setup:

    swacl -l host \     -M group:swadm@`hostname`:a @ remsys1. . .remsysN swacl -l global_soc_template \    -M group:swadm@`hostname`:a @ remsys1. . .remsysN swacl -l global_product_template \    -M group:swadm@`hostname`:a @ remsys1. . .remsysN

You may want to grant permissions to specific users to manage particular products on the primary depot. For example, user ramon may be assigned responsibility to manage the ALLBASE product on your depot, installing new versions and patches when they become available. To add ramon to the ACL for ALLBASE on the local depot and grant him all permissions on that one product, run the command:

swacl -l product -M user:ramon:a ALLBASE

At the same time, you may want to eliminate the ACL entry for group swadm for the same product:

swacl -l product -D group:swadm ALLBASE

Security in Local Distributions

Host administrators may grant permission to individual users or groups, trusted at the local host, to administer software locally. Trusted local users have root ACL entries granting insert and write permissions. At the source depot, access to all software products is allowed by unrestricted read access to hosts, depots, and products. This is the basis of a pull model of software distribution.

Restricting Installation to Specific Target Systems by Specific Users

Managers of software source depots may leave software openly installable, as described above, or may choose to limit distribution to specific systems. ACLs protecting source depot products may contain entries that restrict product read access to only specified systems, allowing installation only to those systems. This restriction applies to both the push and pull models.

Below is a sample product ACL that restricts read permission to systemA and systemB and grants all permissions to user swadm:

user:swadm:rwict host:systemA.loc.company.com:r host:systemB.fc.hp.com:r

Security for Software Developers

Software developers iteratively package their products and test them before distribution. This involves packaging products into depots and installing them to Roots for testing. Since it may require several iterations to get all the customization right, it is not helpful to prevent software developers from having free access to depots and Roots for this testing.

You should also not have products that are being tested, coming and going on wide-use depots and roots. They might accidentally be installed or used before they are ready.

The recommended method of development is to provide one or more development depots and roots for testing purposes, each with protections customized to meet the needs of the development group using them. To this end, the default ACL template mechanism described previously is handy, since products come and go quickly.

A host administrator (someone with insert permission on the host) should create the test depot for developers, then assign a depot administrator and edit the depot ACL to grant that person control (ACL edit) permission on the depot. The depot’s product ACL template should then be set up so that users inserting a product may also write (modify and delete) it, and so that it may be read only by the known test systems.

Similarly, test roots may be created, perhaps on other test hosts, to which developers may install test products. Access to install to the test root should be restricted to the development group.

When testing is complete and a product is ready for release, the product may then be copied to a general distribution depot to make it more widely readable without exposing all the untested products on the test depot.

There are many additional ways in which these basic concepts may be used to implement a desired security policy for product development.

Printable version
Privacy statement Using this site means you accept its terms Feedback to webmaster
© 1997, 2000-2003, 2006, 2007, 2008 Hewlett-Packard Development Company, L.P.