Go to main content

Securing Files and Verifying File Integrity in Oracle® Solaris 11.4

Exit Print View

Updated: August 2018
 
 

Viewing and Testing Sample Label Encodings Files

The examples in this section illustrate how to view and use the label policies that Oracle Solaris provides. The encodings files are simple. The default encodings file illustrates a three-level label hierarchy. The compliance encodings file illustrates disjoint labels. The simplest way to test a label policy is to commit the policy, then create a multilevel ZFS dataset and a few users with clearances that enable them to create and view files in the dataset.

Testing Labeling by Using the Default Encodings File

  1. To test labels, you must set the clearance value to a user label in the default encodings file.

    The following commands list the available labels, set a new clearance value, and display the new clearance.

    # cp label_encodings.default label_encodings.default.orig
    # labelcfg list
    "Confidential - Highly Restricted"
    "Confidential - Restricted"
    "Confidential - Internal"
    Public
    # labelcfg 'set clearance="Confidential - Internal"'
    # labelcfg info clearance
    clearance=Confidential - Internal

    Note -  The clearance value is typed within double quotes because it contains spaces. However, the shell interprets the double quotes and then removes them. When you surround the subcommand with single quotes, the shell removes the single quotes and leaves the double quotes.
  2. Create a labeled file system, mount it, and enable DAC access to any user.

    # zfs create -o multilevel=on -o encryption=on rpool/defaultenc
    # zfs set mountpoint=/defaultenc rpool/defaultenc
    # cd / ; cd rpool
    # chmod 777 defaultenc
  3. Create test users at different clearances. Users who are created without a clearance inherit the default, Confidential - Internal.

    # useradd -m /export/home -K clearance="Confidential - Highly Restricted" high1
    # useradd -m /export/home -K clearance="Confidential - Restricted" rest1
    # useradd -m /export/home test1
  4. Reboot, then test.

    For various items to test, see How to Verify User Access to Labeled Files in Securing Users and Processes in Oracle Solaris 11.4.

  5. After the testing is complete, you can delete the labeled dataset, delete the users with high clearances, and enable the default label encodings file.

    # zfs destroy rpoot/defaultenc
    # userdel -r high1 ; usermod -r rest1 ; usermod -r test1
    # labelcfg -e /etc/security/tsol/label_encodings.default.orig commit
Example 17  Customizing a Test Label Policy

In this example, you modify the existing template with the name of your organization. This example calls the organization “ExampleCo”.

# cd /etc/security/tsol
# cp label_encodings.default label_encodings.exampleco
# labelcfg -e label_encodings.exampleco
labelcfg:label_encodings.exampleco> set title="Data Protection Policy for ExampleCo"
labelcfg:label_encodings.exampleco> select classification="Confidential -"
labelcfg:Confidential -> set shortname="Conf ExampleCo -"
labelcfg:Confidential -> end
labelcfg:label_encodings.exampleco> set clearance="Conf ExampleCo - Internal"
labelcfg:label_encodings.exampleco> commit
labelcfg:label_encodings.exampleco> list
"Conf ExampleCo - Highly Restricted"
"Conf ExampleCo - Restricted"
"Conf ExampleCo - Internal"
Public
labelcfg:label_encodings.exampleco> info clearance
clearance=Conf ExampleCo - Internal
labelcfg:label_encodings.exampleco> exit

After you commit this label policy, regular users at login would be operating at the Conf ExampleCo - Internal label. Only users whom you configure with an explicit higher clearance can access sensitive files labeled as Conf ExampleCo - Restricted or Conf ExampleCo - Highly Restricted.

Testing Labeling by Using the Compliance Encodings File

The sample compliance encodings file contains disjoint labels. Disjoint labels can prevent users from seeing department-private information. In the sample label_encodings.compliance file, the Health Records and Payment Data departments are disjoint. This policy isolates payment data from health records, both of which are highly restricted information. The policy is enabled by the commit command.

  1. Commit then view the label encodings file.

    # cd /etc/security/tsol
    # cp label_encodings.compliance label_encodings.compliance.orig
    # labelcfg -e label_encodings.compliance commit
    # labelcfg info
    title=Sample Data Protection Policy
    classification=Public
    	level=1
    classification=Confidential
    	level=2
    compartment=Highly Restricted
    	subcompartments="Payment Data,Health Records"
    	minclass=Confidential
    compartment=Payment Data
    	bit=0
    	subcompartments="Internal Use Only"
    	conflicts="Health Records"
    	minclass=Confidential
    compartment=Health Records
    	bit=1
    	subcompartments="Internal Use Only"
    	conflicts="Payment Data"
    	minclass=Confidential
    compartment=Internal Use Only
    	bit=2
    	minclass=Confidential
    min_label=Public
    clearance=Confidential Internal Use Only
  2. List the available labels.

    # labelcfg list
    "Confidential Highly Restricted"
    "Confidential Payment Data"
    "Confidential Health Records"
    "Confidential Internal Use Only"
    Public
  3. Create a labeled file system for payment data and health records.

    Add a few payment files and health files, correctly labeled.

  4. Create users with different clearances.

    For example, assign the Confidential Highly Restricted clearance to a user who can access everything, the Confidential Payment Data clearance to a user who can handle only payment data, and the Confidential Health Records to a user who can handle only health records. A user with the Confidential Internal Use Only clearance should not be able to see any payment or health information.

  5. Reboot, then test.