svcadm(8)을 검색하려면 섹션에서 8 을 선택하고, 맨 페이지 이름에 svcadm을 입력하고 검색을 누른다.
clearance(7)
cl...e(7)Standards, Environments, Macros, Character Sets, and miscellancyl...e(7)
NAME
clearance - Solaris process label attribute
DESCRIPTION
Clearance is a process attribute that is used in mandatory policy deci‐
sions. When accessing labeled objects the process clearance must domi‐
nate 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 ob‐
ject's label if its classification is equal to or greater than the ob‐
ject'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 cre‐
ate 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 rep‐
resentations. Labels must be converted to an m_label_t structure before
they can be compared. The translation functions are described in libt‐
sol(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 clear‐
ance 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 clear‐
ances:
1. The default clearance for users and roles is specified via
the clearance property in labelcfg(8). This property is ini‐
tially 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 main‐
tained 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 ex‐
plicitly 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 use‐
ful 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 as‐
sign 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.la‐
bel.file.downgrade authorization allows a user or role to lower the la‐
bel 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 re‐
stricted 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 in‐
cludes 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 inad‐
vertent disclosure of sensitive information. These labels are automati‐
cally 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 au‐
ditreduce(8).
SEE ALSO
plabel(1), sandbox(1), setlabel(1), libtsol(3LIB), getclearance(3TSOL),
setclearance(3TSOL), policy.conf(5), user_attr(5), attributes(7), la‐
bels(7), tpd(7), auditconfig(8), auditreduce(8), labelcfg(8), svc‐
cfg(8), useradd(8), zfs(8), profiles(1), roleadd(8)
Securing Users and Processes in Oracle Solaris 11.4
NOTES
Although file labeling is also available when Trusted Extensions is en‐
abled, the process clearance is not. Instead, Trusted Extensions relies
on zone labels to enforce its mandatory policy.
Oracle Solaris 11.4 21 Jun 2021 cl...e(7)