HP UX Security Products and Features Software manual Capabilities, Identity-based access controls

A FLAC policy prevents modification of file status information such as modification time, permission bits, owner ID, and group ID stored within the file inode.

1.1.2 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.

1.2 Capabilities

The WLI A.01.00 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.

1.2.1mem

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.

1.2.2wmd

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 2.3 (page 16). This capability is useful for backup and restore commands like tar.

1.2.3dlkm

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.

10 Security features