HP UX Whitelisting 1 Security features, 1.1 File access policies, 1.1.1 File lock access controls, wlipolicy, Capabilities, File access policies, access to a protected resource

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