JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Trusted Extensions Developer's Guide     Oracle Solaris 10 1/13 Information Library
search filter icon
search icon

Document Information


1.  Trusted Extensions APIs and Security Policy

2.  Labels and Clearances

3.  Label Code Examples

4.  Printing and the Label APIs

Printing Labeled Output

Designing a Label-Aware Application

Understanding the Multilevel Printing Service

get_peer_label() Label-Aware Function

Determining Whether the Printing Service Is Running in a Labeled Environment

Understanding the Remote Host Credential

Obtaining the Credential and Remote Host Label

Using the label_to_str() Function

Handling Memory Management

Using the Returned Label String

Validating the Label Request Against the Printer's Label Range

5.  Interprocess Communications

6.  Trusted X Window System

7.  Label Builder APIs

8.  Trusted Web Guard Prototype

9.  Experimental Java Bindings for the Solaris Trusted Extensions Label APIs

A.  Programmer's Reference

B.  Trusted Extensions API Reference


Designing a Label-Aware Application

Most applications do not need to be label-aware. Therefore, most Oracle Solaris software applications run under Trusted Extensions without modification. The Trusted Extensions label-based access restriction is designed to operate in a way that is consistent with Oracle Solaris OS standards. Generally, any process that you bind to a multilevel port needs to be label-aware because it receives data at multiple labels and is trusted to enforce the security policy.

For example, an application might not be able to access a resource because the application is running at a label that is lower than the required resource. However, an attempt to access that resource does not result in a special error condition. Instead, the application might issue a File not found error. Or, an application might attempt to access information that has a higher label than the application is allowed to access. However, the security policy dictates that without sufficient privileges, an application cannot be aware of the existence of a resource with a higher label. Therefore, if an application attempts to access a resource with a label that is higher than the application's label, the resulting error condition is not label-specific. The error message is the same as the error message that is returned to an application that tries to access a resource that does not exist. The lack of “special error conditions” helps to enforce security principles.

In Trusted Extensions, the operating system, not the application, enforces the security policy. This security policy is called the the mandatory access control (MAC) policy. For example, an application does not determine if a protected resource is accessible. Ultimately, the operating system enforces the MAC policy. If an application does not have sufficient privileges to access a resource, the resource is not available to the application. Thus, an application does not need to know anything about labels to access labeled resources.

Similarly, most label-aware applications must be designed so that they can operate in a consistent manner with applications that are not label-aware. Label-aware applications must behave in essentially the same way in environments that involve only a single label, in environments that are unlabeled, and in environments that involve multiple labels. An example of a single-label environment is when a user session with a given label mounts a device at the same label. In an unlabeled environment, a label is not explicitly set, but a default label is specified in the tnrhdb database. See the smtnrhdb(1M) man page.