Privileged Operations and Labels
When an operation can bypass or override the security policy, the operation
requires special privileges in its effective set.
Privileges are added to the effective set programmatically or administratively in these
ways:
If the executable file is owned by root and has the set user ID permission bit set, it starts with all privileges in its effective set. For example, the CDE File Manager starts with all privileges in its effective set. Then, File Manager programmatically relinquishes most of its privileges to retain only the ones it needs to perform drag-and-drop operations across labels.
The administrator can specify privileges in manifest files for SMF services or in the RBAC database exec_attr file for general commands. For more information about this file, see the exec_attr(4) man page.
The operation needs special privileges when translating binary labels and when upgrading
or downgrading sensitivity labels.
Users and roles can run operations with special privileges. These privileges can
be specified by using rights profiles. Applications can be written to run certain
functions with certain privileges, as well. When you write an application that
must assume special privileges, make sure that you enable the privilege only
while running the function that needs it and that you remove the
privilege when the function completes. This practice is referred to as privilege bracketing.
For more information, see Solaris Security for Developers Guide.
Translating binary labels – You can translate a label between its internal representation and a string. If the label being translated is not dominated by the label of the process, the calling process requires the sys_trans_label privilege to perform the translation.
Upgrading or downgrading sensitivity labels – You can downgrade or upgrade the sensitivity label on a file. If the file is not owned by the calling process, the calling process requires the file_owner privilege in its effective set. For more information, see the setflabel(3TSOL) man page.
A process can set the sensitivity label on a file system object to a new sensitivity label that does not dominate the object's existing sensitivity label with the file_downgrade_sl privilege in its effective set. The file_downgrade_sl privilege also allows a file to be relabeled to a disjoint label.
A process can set the sensitivity label on a file system object to a new sensitivity label that dominates the object's existing sensitivity label with the file_upgrade_sl privilege in its effective set.
Most applications do not use privileges to bypass access controls because the
applications operate in one of the following ways:
The application is launched at one sensitivity label and accesses data in objects at that same sensitivity label.
The application is launched at one sensitivity label and accesses data in objects at other sensitivity labels, but the mandatory access operations are permitted by the system security policy. For example, read-down is allowed by MAC.
If an application tries to access data at sensitivity labels other than
the sensitivity label of its process and access is denied, the process
needs privileges to gain access. Privileges enable an application to bypass MAC
or DAC. For example, the file_dac_read, file_dac_write, and file_dac_search privileges bypass DAC.
The file_upgrade_sl and file_downgrade_sl privileges bypass MAC. No matter how access is
obtained, the application design must not compromise the classification of the data
that is accessed.
When your application changes its own sensitivity label or the sensitivity label
of another object, be sure to close all file descriptors. An open
file descriptor might leak sensitive data to other processes.