Label Guidelines

This section provides guidelines for you to follow when your program must use privileges to bypass access controls or change the sensitivity label.

Sensitivity Labels

Most applications do not use privileges to bypass access controls because they operate in one of the following ways:

• An application is launched by one user or many users at one sensitivity label and accesses data in objects at that same sensitivity label.

• An application is launched by one user or many users at one sensitivity label and accesses data in objects at other sensitivity labels, but the mandatory access operations are allowed by the system security policy as described in "Security Policy".

• An application is launched by one user or many users at different sensitivity labels and accesses data in objects at that same sensitivity label by way of multilevel directories. Multilevel directories are described in Chapter 7, Multilevel Directories.

If an application accesses data at sensitivity labels other than the sensitivity label of its process and access is denied, the process needs privilege to gain access. Privileges let the application bypass mandatory or discretionary access controls (file_mac_read, file_dac_read, file_mac_write, file_dac_write, file_mac_search or file_dac_search), change the process sensitivity label so mandatory access is granted (proc_setsl), or upgrade or downgrade the sensitivity label of the data (file_upgrade_sl, file_downgrade_sl). No matter how access is obtained, the application design must abide by the guidelines presented here to not compromise the classification of data accessed.

Bypassing Mandatory Access Controls

If you use privileges to bypass mandatory access restrictions, be careful your application does not write data out at a lower sensitivity label than the label at which it read the data. Also, your application design should not allow the accidental downgrading of data due to program errors.

Upgrading or Downgrading Sensitivity Labels

Follow these guidelines when your application changes its own sensitivity label or the sensitivity label of another object.

• Upgrade a sensitivity label whenever possible.

  A program that upgrades a sensitivity label is safer than a program that downgrades a sensitivity label because application errors that cause information leaks upgrade the data, rather than downgrade it. Upgrading data results in the over classification of the data, but is not a security breach. You can use privileges to downgrade a sensitivity label, but use these privileges very carefully.

• Never change a process sensitivity label more than once. Changes to the process sensitivity label increase the possibility of accidentally transmitting data between different levels. Any change to the process sensitivity label is an upgrade or downgrade of the information in the process address space.

• Close all file descriptors when changing a file or process sensitivity label so sensitive data is not available to other processes.

Creating a Process at Another Sensitivity Label

Instead of changing the process sensitivity label, fork() a new process and change the sensitivity label of the forked process so tasks can be performed at another level separate from the data in the forking process. The forked process should either return information to the forking process or send the information to another process.

Information returned by a forked process at a changed sensitivity label should provide no more information than absolutely necessary. For example, provide the success or failure of a computation, and not the actual data. Returning or passing specific information keeps the data used to make the computation secure and prevents data at one level from mixing with data at another level.