Administrator's Guide

1 Security features
HP-UX Whitelisting (WLI) provides security features complementary to discretionary access
controls, sometimes referred to as DAC restrictions. DAC restrictions are based on defined users
and groups, and the ownership and permission bits associated with every type of file. DAC
restrictions are generated through user commands and enforced within the kernel domain on
the processes comprising every application.
WLI is a cryptographic key-based product. Whitelisting security features are based on RSA key
ownership and encryption technology. WLI security features are imposed through RSA signatures
and enforced through signature verification. Therefore, regular files and directories may be
protected from access by any user including superuser.
Whitelisting security features are divided into the following categories:
File access policies WLI users can restrict access to regular and directory files by
generating policies that are enforced within the kernel domain.
WLI then grants access only to applications meeting the policy
requirements for the protected files.
Capabilities When WLI is installed, certain system resources known to be
security risks are prevented from access by all applications. A
user owning an administrator key can authorize a WLI-signed
application to access these resources. Other users, as well as the
owner of the administrator key, can then execute the signed
application and access the protected resource. In WLI
terminology, a capability is granted to an application to permit
access to a protected resource.
1.1 File access policies
WLI file access policies are generated with the wlipolicy command and enforced by WLI
kernel components when access is requested by application threads. Enforcement of these policies
does not include alteration of ownership, permissions bits, and other file status information
stored on physical media. Enforcement is accomplished by cryptographic verification of
application and policy signatures stored in metadata, followed by access denial to threads that
do not meet policy rules.
User ID and group ID values are not factors within WLI policy enforcement. However, the
traditional UNIX ownership and permission bit restrictions are not avoided by files with WLI
file access policies. After WLI allows access to a policy-restricted file, the executing thread
continues into file-system-specific processing as if WLI is not installed.
1.1.1 File lock access controls
This policy type is abbreviated as FLAC in WLI manpages and other literature. A FLAC policy
assigned to a regular file prevents it from being modified, deleted, or renamed within the parent
directory. A FLAC policy permits read access if allowed by file permission bits.
A FLAC policy assigned to a directory prevents its content from changing; files cannot be added
to or deleted from the directory. A FLAC policy on a directory also locks all its files against
modification or renaming. Files in subdirectories of a FLAC-protected directory are not affected.
The user ID or effective user ID of a process is not a factor for enforcement of this policy type.
Even root or the file owner may not override a FLAC policy. A FLAC policy does not replace
file permission bit restrictions. The policy is enforced in addition to permission bit restrictions.
Read and execute permission for a FLAC protected file is controlled entirely by its permission
bits.
1.1 File access policies 9