Administrator's Guide

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