Software Distributor Administrator Guide (September 2010)

products is allowed by unrestricted read access to hosts, depots, and products. This is
the basis of a pull model of software distribution.
9.9.2.1 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
9.9.3 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.
216 SD-UX Security