Case Study: Solaris Trusted Extensions Glenn Faden and Christoph Schuba, Sun Microsystems, Inc
Total Page：16
File Type：pdf, Size：1020Kb
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 X11/NeWS. 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 E3/FB1 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 E3/FB1 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 ofTrusted 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 8.2. SOLARIS COMPATIBILITY 105 of labels is deliberately opaque to users and applications and might change in a future release. At least 256 classifications and 256 compartment bits are supported. When two labels are compared, the first label can be greater than, less than, equal to, or disjoint from the second label. Classifications are compared as integers, and compartments are compared as bit masks. Labels are disjoint when each contains at least one compartment bit which is not present in the other. A label range can be specified by an upper bound (called a clearance), and a lower bound. Administrative roles can use the Trusted Path to assign label ranges to users, network attributes, workstations, and devices. For this MLS policy, two labels are always defined: admin_low and admin_high. The site’s security administrator defines all other labels. The label admin_low is associated with all normal user readable (viewable) Trusted Extensions objects while the label admin_high is associated with all other Trusted Extensions objects. Only administrative users have MLS read (view) access to admin_high objects and only administrative users have MLS write (modify) access to admin_low objects or admin_high objects. Users interact with labels as strings. Graphical user interfaces and command line interfaces present these strings. Human-readable labels are classified at the label that they represent. Thus, the string for a label A is only readable (viewable, translatable to or from human readable to an opaque label data type) by a subject whose label allows read (view) access to that label. In order to store labels in publicly accessible (i.e., admin_low) name service databases, an unclassified internal text form is used. This textual form is not intended to be used in any interfaces other than those that are provided with the Trusted Extensions software release that created this textual form of the label. When the label-based MLS policies are enabled, all data flows are restricted based on a comparison of the labels associated with the subjects requesting access and the objects containing the data. Like other multilevel operating systems, Trusted Extensions meets the requirements of the Common Criteria’s Labeled Security Protection Profile (LSPP) [231] and the Role-Based Access Protection Profile (RBAC) [256]. The Trusted Extensions implementation focuses on maintaining compatibility with existing UNIX systems, maintaining the high performance of UNIX systems, and simplifying administrative tasks. 8.2 SOLARIS COMPATIBILITY Compatibility with thousands of Solaris applications is achieved by building on existing Solaris features and using existing industry standards. No new protocols are required nor new file system attributes. Applications do not need to be modified nor profiled to bring them into conformance with the MLS policy. Instead, the entire application environment is virtualized for each label through the use of Solaris Containers (zones) [175], Solaris primary OS-level virtualization technology. The Solaris Containers facility provides an isolated environment for running applications. Processes running in a zone are prevented from monitoring or interfering with other activity in the system. 106 CHAPTER 8. CASE STUDY: SOLARIS TRUSTED EXTENSIONS Access to other processes, network interfaces, file systems, devices, and inter-process communication facilities are restricted to prevent interaction between processes in different zones. At the same time, each zone has access to its own network stack and name space, enabling per-zone network security enforcement, such as firewalling or IPsec. The approach to map labels with zones is referred to as polyinstantiation because there can be an instance of each resource and service available at each label. However, there is also a unification principle known as a single system image which is applied to the entire operating environment. All the zones are centrally administered from a special, protected global zone which manages the Trusted Computing Base (TCB) known as the Trusted Path. The zones share a single LDAP directory in which network-wide policy is defined, as well as a single name service cache daemon for synchronizing local databases.