SUMMARY 101 Operating Systerm Security

104 CHAPTER 8. CASE STUDY: SOLARIS TRUSTED EXTENSIONS This new approach enables the Solaris operating system to support both traditional Dis- cretionary Access Control DAC policies based on ownership, as well as label-based, Multilevel Security MLS policies. The MLS label-based policies for file systems and networks have been implemented throughout the standard Solaris 10 kernel, its services and utilities. Unless the Trusted Extensions layer is enabled, all labels are equal, so the kernel does not have any MLS requirements to enforce. The Trusted Extensions systems provide a reference monitor implementation for Solaris that enforces an MLS policy. The reference monitor extends the Solaris and traditional UNIX enforce- ment by providing complete mediation and extending file enforcement to network, printing, and devices. Further, Trusted Extensions provides extensive support for labeling objects in the first place. Trusted Extensions does not need to enable transition of process or resource labels, a mechanism commonly used in Domain Type Enforcement DTE. Tamperproofing is improved by reducing the rights on root processes, using limited domains similar to those in DTE. Finally, verification of correctness is limited, as for all retrofitted UNIX systems, by the amount of code reused from insecure systems. However, the focus of the security policy is primarily on secrecy, so the correctness of the secrecy policy can be verified, but understanding the integrity of the system data is an ad hoc process. The trusted computing base of Trusted Extensions included the kernel and a variety of admin- istrative applications. Importantly, a variety of administrative applications also have to be modified to be MLS-aware, so that they can assist the operating system in the enforcement of MLS require- ments. For example, authentication services must be capable of determining MLS labels for users as they login.

8.1 TRUSTED EXTENSIONS ACCESS CONTROL

The Trusted Extensions access control model supports secrecy protection via MLS, process confine- ment in a manner similar to DTE, and ad hoc privileges to work around limitations of the first two policies. First, both sensitivity levels and categories are used to describe the possible information flows in a system. Second, Trusted Extensions adds roles for limiting the rights of processes that traditionally ran as root, like domains in DTE. As a result, root is only used at installation time, so no processes run with full privilege. Third, discrete rights exceptional to the above two policies may be granted to an application using Solaris privileges. There are at least 68 different kinds of discrete privileges that may be granted. The default mandatory policy of Trusted Extensions is a mandatory, multilevel security MLS policy that is equivalent to that of the Bell-LaPadula Model [ 23 ] of the Lattice, the Simple Security Property, and the ⋆-Property Star Property, with restricted write up. The default mandatory policy is also equivalent to the Goguen and Mesegeur model [ 113 ] of Non-Interference. Labels consist of hierarchical components called classifications or levels and a nonhierarchi- cal components called compartments or categories. The mapping of names to classifications and compartments is specified in a database which is private to the Trusted Path. The internal structure