HP-UX Whitelisting A.01.02 Administrator Guide (766164-001, March 2014)

Identity-based access controls
Abbreviated as IBAC, this policy type denies access to a designated file or directory for all
executables except those specifically authorized. File or directory access is normally granted to
an executing binary if all access restrictions are met. In addition to traditional UNIX restrictions,
an IBAC policy identifies a specific executable binary that, once authenticated, is permitted to
access the protected file. A single file can have multiple IBAC policies, each one identifying a
particular executable.
An IBAC policy prevents unauthorized executables from opening a file. An executable specified
in an IBAC policy is sometimes referred to as an authorized executable for the IBAC-protected file.
If access to an IBAC protected file is permitted by WLI, then read, write, and execute permissions
are determined by the file permission bits and effective userid. Other restrictions imposed outside
of WLI, such as ACLs, are not be affected by WLI.
The user ID or effective user ID of a process is not directly involved in the enforcement of this policy
type as well. A binary executable must have a valid WLI signature for it to be included in an IBAC
policy. When an IBAC protected file is opened, the signature on the binary executing the open()
is verified through the corresponding public key.
Capabilities
The WLI A.01.02 release provides the following capabilities corresponding to system operations
that are protected when WLI security mode is restricted. Capabilities may be granted to binary
executables on a permanent basis using wlisign, or only for a single execution with wliwrap.
mem
WLI does not allow read or write operations on the memory image files /dev/mem and /dev/
kmem unless mem capability is granted to the binary executable attempting the open(). Some
commands like adb open the memory image files to query and update kernel memory. Because
these are device special files, WLI file access policies cannot be assigned to them.
If mem capability is granted to an executing process that is attempting to open one of the memory
image files, the open() is still subject to failure from traditional open() restrictions such as those
imposed by file permission bits.
wmd
WLI does not allow its metadata to be created or written to unless wmd capability is granted to the
executable requesting access. The wmd capability also allows read access on metadata files with
WLI read protection. These restrictions are enforced whether the metadata is stored in VxFS name
streams or protected metadata files. For more information about WLI metadata files, see Section
(page 13). This capability is useful for backup and restore commands like tar.
dlkm
WLI permits the system to load a DLKM if the DLKM has been signed with wlisign using an
authorized key. The signature on the DLKM is not required to include dlkm capability. The
authorized key used for the signing also does not require dlkm capability.
Unsigned DLKMs can also be loaded. If the key authorizing wliwrap execution is granted dlkm
capability, the wliwrap command grants dlkm capability to its child process. The child process
can be an executing instance of kcmodule. The command file /usr/sbin/kcmodule must also
be signed to be recognized as an authorized executable. The signature on /usr/sbin/kcmodule
is not required to include dlkm capability.
This capability is intended to alleviate a security issue associated with dynamic loading. The user
must have root authority to dynamically load, and a WLI administrator key must grant dlkm
capability directly or through another authorized key.
8 Security features