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.