Security Use Models

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:

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.