Go to main content

Securing Files and Verifying File Integrity in Oracle® Solaris 11.4

Exit Print View

Updated: August 2018
 
 

About Labeling in Oracle Solaris

Oracle Solaris enables you to configure systems that enforce company security policy in software by using labels. You can use provided labels or customize the labels to display your organization's security phrases, such as Confidential - Internal Only. An Oracle Solaris label policy enables you to assign these labels to existing or new file systems that contain sensitive data, and assign a set of trusted users the ability to access the files based on the users' clearances. This selective access is useful for file systems that contain data such as credit card numbers, financial records, and marketing plans. Regular users will work within your default label policy, such as Confidential - Internal Only. They cannot access files at a higher security level, such as Confidential - Restricted.

You can use labeling with other features of Oracle Solaris, including package update, immutable zones, automated install, and SMF to provide robust and easily maintained systems that protect data at every stage of the lifecycle, from file creation to file archival and retrieval. This section provides an overview of labeling terminology and use in Oracle Solaris.

Label Policy

Labels in Oracle Solaris implement a set of access rules for sensitive data that is in addition to discretionary access control (DAC). You configure labels to reflect your site's security policy around sensitive data.

All Oracle Solaris systems have a label policy. By default, the policy is unrestricted so that only DAC controls access to files. A default encodings file enforces this unrestricted label policy. The labeling service that runs on all Oracle Solaris 11.4 systems is labeld:clearance.

Label policy is configured in an encodings file. Oracle Solaris provides two sample encodings files: the default file and a compliance encodings file. To view these files, see Viewing and Testing Sample Label Encodings Files.

Every system that contains sensitive data must contain a copy of your customized encodings file. One strategy is to put sensitive data in zones on designated systems, label the ZFS datasets in those zones, and restrict access to the data by labeled user processes and SMF service processes.

Most of your file systems will not be labeled. Therefore, their files inherit the system's lowest label, ADMIN_LOW. All clearances that you assign to users and processes dominate this label, so all files on unlabeled systems are available to all logins.

To administer labels you must be in the root role or be assigned the Object Label Management rights profile.

Labels and Clearances

Oracle Solaris labels files and processes. Labels are assigned to files to indicate the sensitivity of the information. When assigned to processes, labels are called clearances. Processes such as user processes can access files equal to or lower than the process label. Typical labels are Public and Confidential - Restricted.

Oracle Solaris provides the highest and lowest labels, ADMIN_HIGH and ADMIN_LOW. These labels cannot be changed or internationalized. The ADMIN_HIGH label is number 255 and dominates all classifications and includes all compartments. The ADMIN_LOW label, number 0, is the lowest classification and contains no compartments. All labels dominate ADMIN_LOW. On an unlabeled system, the ADMIN_LOW label cannot be changed. Processes with a clearance can access files that the clearance dominates. For example, a process that runs at Confidential - Restricted can access files at that label and at the Public label.

Label Components

Labels and clearances consist of a single classification and zero or more compartments. The classification portion of a label indicates a relative level of trust. Classifications are hierarchical – a higher classification number indicates a higher level of trust. When a label is assigned to a file, the label's classification is one indication of the sensitivity of the information that the file contains.

Compartments provide a more fine-grained mechanism for specifying the user's level of trust. Compartments are typically used to indicate the scope of the trust. For example, a Human Resources compartment would indicate that the level of trust applies to Human Resource materials. When a clearance is assigned to a user, the classification portion of the clearance label indicates the user's level of trust and the compartment bits typically indicate the department where that level of trust applies.

In contrast to label numbers, the compartment bit numbers do not indicate dominance. However, compartments with subcompartments form a hierarchy that can be used to indicate levels of trust, such as the bits for Highly Restricted including the bit defined for Restricted.

Each classification corresponds to a unique positive integer from 0 to 255. Higher numbers dominate lower numbers. A label dominates another label if its classification is at least equal to the other label's classification and its compartments include all the bits in the other label's compartments.

Each compartment corresponds to one or more bits. In Oracle Solaris, the number of available compartment bits is 256, but many thousands of compartments can be created from these bits. You can use compartment bits to define hierarchical, disjoint, and overlapping relationships, as described in Label Relationships. Oracle Solaris assigns bit numbers to the compartments that you name. You can change the bit assignments.

As the administrator, you name your classifications from the lowest classification to the highest and Oracle Solaris assigns the numbers. You can modify the number assignments to redefine the hierarchy. The classification numbers you can use range from 1 to 254.

In the following figure, the label has been assigned a classification of 2. The classification name is "Confidential - ". The compartment names are Internal and Restricted. The Confidential - Internal label uses the classification value and one compartment bit. The Confidential - Restricted label uses the classification value and two bits, compartments 1 and 2.

Figure 1  Sample Label Definitions

image:Graphic shows the Confidential - Restricted and               Confidential - Internal definitions.

Label Relationships

    Labels can have hierarchical relationships, disjoint relationships, and overlapping relationships. For a label encodings file that illustrates these relationships, see Example - Label Encodings File With Reused Compartment Bits.

  • Hierarchical relationships are formed when a label dominates another label. A label dominates another label when its classification is at least equal to the other's classification and its compartments include all the bits in the other's compartments. For example, a classification that you created named Confidential that Oracle Solaris might represent internally as number 3 dominates a classification that you created named Public that is internally represented as 1.

    Compartments are represented as arbitrary numbers. Compartments can be hierarchical when the bits of a subcompartment are a subset of one or more other compartments. Subcompartments can also include their own subcompartments. These subcompartments can contain unique bits in addition to the subsets of the compartment bits. A simple example of a compartment and a subcompartment is Highly Restricted with the Restricted subcompartment. Internally, Oracle Solaris adds the Restricted bit to the Highly Restricted bit, so if the Restricted subcompartment is bit 2, Highly Restricted might be bits 2 and 3.

  • Disjoint relationships are formed when labels with the same classification have different compartment bits. You can also specify that labels conflict. Disjoint labels are useful to isolate sensitive department information from personnel outside the department. For example, you might create the labels Confidential - Finance: Payroll and Confidential - Finance: Accounts to be disjoint.

  • Overlapping relationships are formed when compartments share one or more bits but each compartment has at least one unique bit. Overlapping labels are useful to define an alias, such as an Information Technology alias for writers, course developers, web content providers, and editors.

Privileges for Translating Labels

Label translation occurs whenever programs manipulate labels. Labels are translated to and from the textual strings to the internal representation. For example, when a program such as getlabel obtains the label of a file, before the label can be displayed to the user, the internal representation of the label is translated into readable output, that is, into a textual string. When the setlabel program sets a label specified on the command line, the textual string (that is, the label's name) is translated into the label's internal representation. Oracle Solaris permits label translations only if the calling process's label dominates the label that is to be translated. If a process attempts to translate a label that the process's label does not dominate, the translation is disallowed. The sys_trans_label privilege is required to override this restriction.

Labeled Files and Multilevel File Systems

Labeled files are files that your organization labels due to the sensitivity of their contents. Labeled files are in labeled file systems. Another name for a labeled file system is a multilevel file system.

Labeled file systems can have stricter requirements for encryption, auditing, and other security processes. The auditing of access to sensitive files is part of due diligence. The audit record includes both the label of the file and clearance of the active process. The audit service enables you to specify that file-read events are audited for labeled files only.

Labeled file systems complement encryption. Labeling protects data in mounted file systems, while encryption protects data in unmounted file systems, so archived labeled file systems should be encrypted.

By default, all file systems are unlabeled. In a multilevel file system, files can inherit their label from their directory or be assigned a label explicitly by a user whose process dominates the file label. No privilege can override the access policy specified by a label. You must be an administrator to create a labeled file system.

A user's clearance controls whether they can access a labeled file, upgrade or downgrade a file label, archive a multilevel file system, or restore it. The files that the user is operating on must be within the user's clearance. DAC permissions control whether the user can read, write, or execute the file. Note that discretionary access control (DAC) applies to all labeled files.

Sharing and Mounting Labeled File Systems

Labeled file systems can be shared and mounted. Without an explicit labeled=on option, only the ADMIN_LOW file systems are shared. With the explicit labeled=on keyword, users who are cleared at particular labels can access files at those labels.

Access to files on a remotely mounted labeled file system is enforced by the file server's policy. Access is based on the user's clearance as interpreted by the server. Access policy can either be stored locally on the file server or retrieved from a central LDAP repository. Users must have a clearance on the server that is equal to or higher than the files that they want to access. If the file system is not shared as a labeled file system, remote access is limited to ADMIN_LOW files, even by privileged users.

Only Oracle Solaris systems that support labeling can mount multilevel file systems. To prevent mount failures, set canmount=off for labeled file systems before booting into a non Oracle Solaris 11.4 system.