Software Distributor Administration Guide HP-UX 11i v1, 11i v2, and 11i v3 (5900-2561, March 2013)
entry, of each product. It also grants permission to read (i.e., install) and test the product to
any host (the any_other entry).
object_owner:crwit
any_other:-r---
• In addition to encompassing all hosts, the any_other entry also applies to all other users
except, in this case, the product’s owner. In SD-UX however, product read permission has
meaning only to host principals, and other possible product permissions never apply to hosts;
therefore, the any_other entry may be overloaded with user and host permissions, if desired,
without any danger of ambiguity. This overloading should be kept in mind when using the
SD-UX to execute solutions.
These host ACL defaults provide a good starting point for control over the management functions
of SD-UX while providing open access to read the software for installation on root targets.
9.6 Security on SD-UX Systems
Controlling access to data is a key concern of computer security. In SD-UX, file owners and
superusers allow or deny access to files on a need-to-know basis by setting or manipulating the
file’s permission bits to grant or restrict access by owner, group and others. For example, the
following file listing:
-rwxr-xr 1 doug admin 738 Mar 26 12:25 datafile
shows that:
• File owner is user doug.
• File’s group is admin.
• Name of the file is datafile.
• Owner permissions are read, write and execute (rwx).
• Group permissions are read and execute (r-x).
• Other permissions are read only (r-).
SD-UX commands are essentially object managers that use the SD-UX file system in which to store
their objects. There is no need to obtain access to any objects via the file system, so the file system
protection scheme is based on blocking access to the file system directories that store these objects.
In addition to SD-UX objects, there are several administrative files (log, configuration, and session
files) that are used or managed by SD-UX. These files are not actually SD-UX objects and are
accessible via conventional commands such as editors and printing utilities. These files are protected
by conventional file system protection modes.
Many of the functions that the SD-UX agents do are privileged. Some operations, such as installing
files in system directories (e.g., in the /etc and /dev directories) and customization of system
files via control scripts, require superuser privileges. For this reason, SD-UX agents must always
run as the superuser.
Any system user may run the SD-UX controller; it is not restricted to use only by superuser. In general,
the controller does its work by making Remote Procedure Calls (RPC) to target hosts, but it also
requires special privileges occasionally to access critical log, configuration, and session security
files. Controllers are set-uid root programs that run with the superuser privilege in effect only
briefly to do critical privileged operations, then they switch to the real uid of the user.
Here is a summary of the SD-UX file system protection scheme:
9.6 Security on SD-UX Systems 161