wli.5 (2011 03)

wli(5) Optional WLI Product Required
wli(5)
Enforcement of all IBAC and FLAC policies can be enabled and disabled only with an authorized
administrator key and wlisyspolicy (1M). Disabling policy enforcement will require a system reboot if the
security downgrade policy is set to deferred.
CAPABILITIES
WLI can restrict certain operations to a set of users and executables through the granting of capabilities.
A WLI administrator may grant a user one or more capabilities with wlicert (1M). Binary executables are
granted one or more capabilities through wlisign (1). One or more capabilities can be granted to an exe-
cutable only for the duration of the executing process with wliwrap (1). Both the public key of the
effective user ID (EUID) of the executing process and signature of the executable file must have the capa-
bility assigned for the operation to succeed.
Enforcement of a capability by WLI does not replace restrictions imposed by other system components
such as file system DAC policies. Restrictions imposed by capabilities are generally complementary to
existing security features.
The capabilities defined for the current release are:
•
mem - Ability for a process to read or write to the memory image files
/dev/mem and
/dev/kmem. See mem(7) and kmem(7) for details on the memory image files. The mem capa-
bility is necessary for commands like adb(1) to read from or write to a memory location through
the /dev/mem and dev/kmem special files. The HP-UX restriction that an effective user ID of
0 for write access to these special files is also honored by WLI.
•
wmd - Ability for a process to link/unlink WLI metadata to/from a file. WLI file policy metadata
is normally written through the wlipolicy (1) command. To enable restoration of WLI policy pro-
tected files from archives like those produced by the tar (1) command, wmd capability is neces-
sary. Please consult the HP-UX Whitelisting Version A.01.00 Administrator Guide for a discus-
sion of backup and restore procedures for policy protected files.
•
dlkm - Ability for a process to load an unsigned DLKM module. See kcmodule(1M) for more
information on how to load DLKM modules. The designated binary is permitted to load unsigned
DLKM modules.
•
api - Ability for a process to perform WLI API operations. See libwliapi (3) for more informa-
tion.
SIGNATURES
When a WLI signature is generated for an ELF executable, a WLI metadata section is generated and
stored within the executable. For non-ELF binaries compiled on PA-RISC platforms the metadata is
stored in separate files that are read and write protected by WLI. These non-ELF metadata files are
stored in directories named
.$WLI_SIGNATURE$
that reside under the parent directory of the signed
executable. WLI signatures and metadata are managed with wlisign (1). Information stored in signature
metadata derived from wlisign (1) option values, include:
•
signature - A cryptographic hash of critical sections of the binary executable are signed with
the user’s RSA private key. The RSA private key is generated from OpenSSL genrsa(1). All WLI
command options require keys to be stored in PEM-formatted files produced by openssl (1) sub-
commands.
•
public key fingerprint - The user must obtain a public key extracted from the RSA
private key. OpenSSL rsa (1) will extract a public key from an RSA private key. A cryptographic
fingerprint is generated and stored within the WLI database for recognition of authorized keys.
•
owner ID - The effective user ID (EUID) of the process creating the signature.
•
appid - The application ID of a signed executable is a unique, cryptographically generated hash
identifies a signed executable within an IBAC policy record.
•
prodid - The product ID is an alphanumeric string, chosen by the signer, that can be used to
identify a group of signed executables within an IBAC policy record.
•
capabilities - The CAPABILITIES section lists the optional attributes that can be added
only by a WLI administrator. If the owner’s public key in the WLI database has the same capa-
bility, operations involving the capability are allowed.
Any RSA private key in PEM format can be used to sign a binary executable. A signed executable can
only be authenticated for file access policies or
capabilities if a WLI administrator key has author-
ized the key. WLI user keys are authorized with wlicert (1M) and administrator keys are authorized with
2 Hewlett-Packard Company − 2 − HP-UX 11iv3: Sep 2010 Web Release