Go to main content

man pages section 7: Standards, Environments, Macros, Character Sets, and Miscellany

Exit Print View

Updated: Wednesday, July 27, 2022



clearance - Solaris process label attribute


Clearance is a process attribute that is used in mandatory policy decisions. When accessing labeled objects the process clearance must dominate the label of the object. Both clearances and object labels consist of integer components corresponding to a classification name, and a bit mask corresponding to compartment names. A clearance dominates an object's label if its classification is equal to or greater than the object's label, and its compartment bits include all of the compartment bits in the object's label. Identical labels dominate each other. If each of the labels has at least one unique compartment bit, then the relationship is disjoint because neither dominates the other.

The relationships between classification names and compartment names is specified using labelcfg(8). Various constraints can be defined to create hierarchical and disjoint sets of labels. The label specification is compiled into an internal format by the svc:/system/labeld:clearance service which translates labels between the internal and external representations. Labels must be converted to an m_label_t structure before they can be compared. The translation functions are described in libtsol(3LIB).

Process clearances are maintained in the credential structure in the kernel. By default, processes are assigned a maximum value, ADMIN_HIGH, which dominates every other label. Process clearances can be lowered, but not raised. Users may use the sandbox command to start processes at a lower clearance. By default the clearance is lowered to ADMIN_LOW, which is dominated by every other label. Once lowered, the new clearance is inherited by child processes. The setclearance(3TSOL) function can be used to lower the current process clearance programmatically. This function does not require any privilege. However, it cannot be used to raise a process clearance, even with all privileges.

Administrative Interfaces

There are four administrative interfaces for setting process clearances:

  1. The default clearance for users and roles is specified via the clearance property in labelcfg(8). This property is initially set to ADMIN_HIGH, so users are not constrained by any labeling policies. Setting an explicit default clearance is a prerequisite when configuring a label policy.

  2. The clearance for specific users and roles is set via the clearance property using useradd(8) or roleadd(8), and maintained in user_attr(5).

  3. Clearances for SMF service instances are specified via the method_context/clearance property, using svccfg(8). If not specified, the clearance defaults to the value specified by the CLEARANCE property in policy.conf(5). Note that services that rely on PAM to authenticate user sessions should be explicitly assigned the ADMIN_HIGH label so that PAM can set the appropriate session clearance.

  4. Clearances for individual commands are specified via the clearance property using profiles(1). This is primarily useful when roles with a higher clearance are assumed by users with a lower clearance. Since role assumption cannot be used to raise the process clearance, it may be appropriate to assign roles a rights profile which includes commands that run at specific clearances. Such commands will be executed at the specified clearance if the role's clearance (set in user_attr(5)), dominates the command's clearance.

Mandatory Policy

The plabel(1) command can be used to show the clearance of other processes. However, the current process must have normal access to the target process and must dominate the target process's clearance. The same restrictions apply to debugging tools such as dtrace(8), mdb(1), dbx(1), truss(1), and other proc(1) tools.

When accessing files or directories in ZFS filesystems in which the multilevel property is enabled, the process clearance must dominate the file or directory label. Directory listings only show entries that are dominated by the current process clearance.

A user or role with the solaris.label.file.upgrade authorization may use setlabel(1) to upgrade a file or directory to a new label that is dominated by the current process clearance. Similarly, the solaris.label.file.downgrade authorization allows a user or role to lower the label if the existing label is dominated by current process clearance.

ZFS multilevel filesystems maintain an upper bound label which floats up when a file or directory is upgraded. The maximum label of the file system can be observed using the ZFS mlslabel property, but it cannot be lowered. To send or archive a labeled file system the current process clearance must dominate the mlslabel property.

Device Policy

Devices that are configured with add_drv(8) or update_drv(8) can be restricted to require the ADMIN_HIGH process clearance by setting the policy token require_admin_high=true. This includes devices such as /dev/kmem.

Immutable Policy

If the current zone is configured to be immutable (see mac(9F)) then the ADMIN_HIGH process clearance is required to modify specific SMF properties. Note that all processes that are marked as part of the Trusted Path Domain (see tpd(7)), are started with the ADMIN_HIGH clearance.

SMF properties that permit reconfiguration of the security policy can only be modified by processes with the ADMIN_HIGH clearance. This includes any method or sysconfig properties. For example, changing the process clearance of an existing service, or reconfiguring the name service requires the ADMIN_HIGH clearance.

Auditing and Data Loss Prevention

Directories can be assigned restricted labels to mitigate against inadvertent disclosure of sensitive information. These labels are automatically applied to any files or directories created under them. Users and roles with a need to know can be assigned clearances corresponding to these labels. Such files and directories will be hidden from users with insufficient clearances. Authorized users may upgrade or downgrade files and directories to further restrict access. Disjoint labels can be used to facilitate separation of duty.

The audit trail can be used to facilitate compliance reporting. Audit events that include file attributes also include file labels unless they are unlabeled. To minimize the volume of irrelevant audit data, the audit policy can be configured to only audit open-for-read events that correspond to explicitly labeled files using the unlabeled option of auditconfig(8). Audit events matching a specific file label, or range may be filtered using the –l option of auditreduce(8).

The process clearance is automatically recorded in the audit trail for any events which include process attributes. Events matching a specific process clearance, or range may be filtered using the –L option of auditreduce(8).

See Also

plabel(1), sandbox(1), setlabel(1), libtsol(3LIB), getclearance(3TSOL), setclearance(3TSOL), policy.conf(5), user_attr(5), attributes(7), labels(7), tpd(7), auditconfig(8), auditreduce(8), labelcfg(8), svccfg(8), useradd(8), zfs(8), profiles(1), roleadd(8)

Securing Users and Processes in Oracle Solaris 11.4


Although file labeling is also available when Trusted Extensions is enabled, the process clearance is not. Instead, Trusted Extensions relies on zone labels to enforce its mandatory policy.