RECENT UNIX SYSTEMS UNIX ERA 99

103 C H A P T E R 8 Case Study: Solaris Trusted Extensions Glenn Faden and Christoph Schuba, Sun Microsystems, Inc. Solaris TM Trusted Extensions is a feature of the Sun Microsystems’s Solaris operating system that enforces multilevel security MLS policies [ 23 ]. It is the latest in a series of MLS workstation and server operating systems that have been under development at Sun since 1988. The first version, SunOS MLS 1.0, which appeared in 1990, was based on the SunView window system. It was designed to meet the TCSEC B1 level [ 304 ], see Chapter 12. However, it was replaced in 1992 by SunOS CMW, which was designed to meet the Compartmented Mode Workstation Requirements, CMWREQS [ 25 , 340 ]. SunOS CMW was based on OpenWindows and X11NeWS. It supported both sensitivity labels for Mandatory Access Control, and floating information labels for human consumption. It was first certified using the ITSEC Scheme at the E3FB1 level in 1992. Trusted Solaris 2.5 through Trusted Solaris 8 were based on the Common Desktop Environ- ment CDE and X11 [ 227 ]. Trusted Solaris 2.5.1 was also certified using the ITSEC scheme at the E3FB1 level in 1996. Trusted Solaris 8 was evaluated using the Common Criteria scheme in 2000, with an assurance level of EAL4+. It was certified to meet the Controlled Access CAPP [ 230 ], Role-Based Access RBACPP [ 256 ], and Label Security Protection LSPP [ 231 ] Profiles. The RBAC features of Trusted Solaris were incorporated into the standard Solaris OS at that time. As- surance is detailed in Chapter 12, but in general, the assurance validates the correct low-level design for enforcing MLS requirements. Based on this assurance, Trusted Solaris has a dominant share in the U.S. Department of Defense and intelligence communities. In 2001 Sun began work to unify its two Solaris versions, which was completed in 2006, with the release of Solaris 10, update 3, which included the Trusted Extensions [ 1 ]. Also at that time, Sun contributed the source code for the kernel and window system to the OpenSolaris community. In addition to removing the need for separate kernels, the integration also made it possible to support MLS on x86, x64, and SPARC platforms. Trusted Extensions includes an MLS version of the GNOME desktop. The combined Solaris system with Trusted Extensions received Common Criteria certification at the EAL4+ assurance level in June 2008, using the same three protection profiles. The authors of this chapter would like to thank their colleagues in the Sun Solaris Security Organization, especially Casper Dik, Gary Winiger, Darren Moffat, and Glenn Brunette, for their contributions and reviews. 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