 Print-friendly Version
Comparing the Multilevel Security Policies of the Solaris Trusted Extensions and Red Hat Enterprise Linux SystemsGlenn Faden (Distinguished Engineer, Sun Microsystems), February 2007 Sun Microsystems, Inc. and Red Hat have both submitted new versions of their trusted operating systems (OS) for Common Criteria (CC) certification evaluation. While these systems are being evaluated against the same CC protection profiles and at the same evaluation assurance level, these systems differ in significant ways that affect how a customer might choose to use such systems. The new Sun Solaris Trusted Extensions (Trusted Extensions) software implements its multilevel security (MLS) policy based on the Solaris Containers model, which uses labeled zones. Instead, Red Hat's approach is to create an MLS policy configuration that extends the type enforcement policy implemented in Security-Enhanced Linux (SELinux). When divergent approaches are taken to create systems to meet the same set of requirements, it is difficult to make a fair comparison of those systems. Red Hat and its partners HP and IBM have published several articles about the path to multilevel security [1, 2]. These articles say little or nothing about Trusted Extensions, which is the current Sun product. Instead, these articles compare the upcoming release of Red Hat Enterprise Linux 5 (RHEL5), which includes the SELinux module, to the six-year-old Trusted Solaris 8 product. This article, on the other hand, identifies and contrasts the comparable MLS features of Trusted Extensions with those that are part of the RHEL5 MLS policy configuration, which Red Hat refers to as RHEL5 LSPP. Both systems are in active development stages. So, this document bases its comparison on the software available in February 2007. Subsequent changes to these systems might invalidate some of the comparisons made in this article. This discussion covers the following topics:
Overview of the Trusted Extensions and RHEL5 LSPP SystemsThe Solaris 10 Operating System provides new frameworks for containment (zones), user rights management (roles and authorizations), and process rights management (privileges). The Trusted Extensions software, introduced in the Solaris 10 11/06 OS, extends these frameworks by adding sensitivity labels to provide a mandatory access control (MAC) policy base that implements multilevel security. Since the Trusted Extensions software preserves all the basic Solaris OS functionality, new features added to the Solaris OS are, by definition, compatible with Trusted Extensions. The Red Hat Enterprise Linux 5 OS includes SELinux, which is a framework for describing a security policy based on security contexts. A security context consists of a user identity, a role, a type, and an optional MLS level or range. The user identity attribute in the security context is independent of the ordinary Linux user identity attributes. The SELinux mandatory access controls remain completely orthogonal to the existing Linux access controls. As a result, a process must pass standard policy controls before anything from the SELinux module applies. Neither RHEL5 LSPP nor the Solaris 10 11/06 OS enables the use of sensitivity labels by default. Overview of Common Criteria Certification EvaluationThe Common Criteria (CC) is an international standard for computer security [3]. This standard describes a framework for users to specify requirements, vendors to implement them, and testers to evaluate the implementation against the requirements. A protection profile describes the requirements created by a user or user community. A vendor implements the protection profile requirements in its products or makes claims about the security attributes of its products. Finally, the vendor submits the products to a testing laboratory to be evaluated for a specific protection profile at a specific evaluation assurance level (EAL). The vendor can include or exclude functionality from the submitted product if the vendor feels that such functionality will not meet the strict security testing standards required. When labels are enabled and the corresponding components for auditing and administrative roles are configured, both the Solaris 10 11/06 OS and RHEL5 are intended to meet the following protection profiles:
An evaluation is performed at a specified EAL, which specifies the thoroughness of the evaluation. EAL4 is the highest assurance level that is valid for the entire international community. When evaluating at EAL4, the vendor provides design documents, tests, source code, and access to architects for conversations with the evaluators. EAL4+ indicates that the system has been evaluated at EAL4, with one item evaluated at EAL5. A CC system evaluation is focused solely on the areas addressed by the specified protection profile. This testing does not include the evaluation of other aspects of the system, such as performance or the feature set. The Solaris 10 3/05 OS has been successfully evaluated at EAL4+ for CAPP and RBACPP. The Solaris 10 11/06 OS with Trusted Extensions has been submitted for evaluation at EAL4+ for RBACPP and LSPP. This submission includes both client (desktop) and server configurations. RHEL5 has not yet completed any CC evaluations. MLS Feature ComparisonThis article compares these labeling-enabled systems: the Solaris 10 11/06 system with Trusted Extensions and the RHEL5 LSPP system. This section provides a detailed comparison of the system implementations in several functional areas. For a feature comparison summary, see Solaris Trusted Extensions and Red Hat Enterprise Linux: Multilevel Security Policy Feature Summary Comparison. Each functional section compares the implementations and describes issues related to CC certification evaluation, if appropriate. Multiple Policy Configurations A system can support more than one policy configuration to help tailor an environment for specific uses. RHEL5 supports three configurations of the SELinux policy:
The Solaris 10 OS does not support policy configurations, per se. However, the Solaris 10 11/06 OS does provide a limited network services profile called Secure by Default Networking that is roughly equivalent to the RHEL5 Targeted policy. Solaris 10 11/06 with Trusted Extensions enabled is comparable to RHEL5 LSPP. The Solaris 10 OS does not provide an equivalent to the Strict policy. None of the CC protection profiles requires that multiple policy configurations be supported by an OS. The RHEL4 Targeted policy has already been certified for CAPP at the EAL4+ level. The Strict policy has not been part of a CC evaluation by a Linux vendor. The RHEL5 MLS policy configuration was designed to meet the additional requirements for RBACPP and LSPP. The Solaris 10 3/05 release has already been certified for both CAPP and RBACPP at the EAL4+ level. The Solaris 10 11/06 OS with Trusted Extensions enabled has been submitted for evaluation for RBACPP and LSPP at the EAL4+ level. Policy Hooks SELinux is an optional security module that is loaded into the Linux kernel at boot time. This module is accessed through an extensible framework known as Linux Security Modules (LSM), which modularizes access control. Discretionary access control (DAC) is not included in the module, as the focus is on mandatory access policies. Additional security modules can be loaded into the LSM framework, such as the default Capabilities module and Novell AppArmor [4], which is an alternative to the SELinux module. Similarly, the Solaris security policy is abstracted by means of a
private set of policy hooks. The policy hook functions use Sun could have delivered these functions as a loadable module, as was done for the original implementation of the Trusted Solaris 8 OS. However, experience with the Trusted Solaris OS showed that supporting multiple policy implementations was difficult. So, the Solaris 10 kernel was designed to always enforce policy based on process privileges. No mechanism exists to load alternate policies or to disable the privilege policy. Thus, the Solaris 10 OS is a fully privilege-aware OS at all times. Integration With the OS Both the Linux OS and the Solaris OS are available as open source. Trusted Extensions is tightly integrated into the Solaris 10 11/06 OS and most of the Trusted Extensions code has been merged with standard Solaris source trees. Plans are in place to merge the few remaining files. SELinux, on the other hand, is an optional module that is included with the RHEL5 OS but is not part of most distributions, such as SUSE Linux. Since SELinux must interface with the Linux kernel through the LSM interface, the aspects of access control that it can enforce are limited to those defined by the LSM interface rather than to all the requirements specified by the LSPP. Flexible Policy The rules for MLS data flow and for relabeling are precisely specified by the LSPP, so by definition, MLS is not a flexible policy. The RHEL5 MLS policy configuration is an extension of the Linux type enforcement policy. As such, the policy is defined by using policy language primitives that are similar to those used to define types. In RHEL5 LSPP, it is necessary to explicitly declare the MLS rules for all object classes, since no inherent MLS policy is implemented in the kernel. Thus, for every application, file, user, network, or process that a customer wants to access, essentially anything on the system, a specific line in a security policy configuration file must be written. This can lead to extremely long and fragile security policy files that must be changed each time a new capability is exercised for an application that was tested during policy development. Each change in a security policy file requires a reload of the security policy in the kernel, which often requires a reboot of the RHEL5 system. By contrast, the Trusted Extensions MLS policy for file systems and for networking is hard-coded in the Solaris kernel and is always in effect when labeling is enabled. The MLS policy is consistent and reliable because it does not rely on complex policy files to enumerate appropriate information flows. Trusted Extensions has a more lightweight implementation of the MLS policy and is easier to administer than the RHEL5 LSPP or Trusted Solaris 8 implementations. Policy files are not typically changed just because a new application is added to the system. A new application is automatically subject to labeled security policy controls based on the zone in which the application is run. Changes to networking or to label ranges might require the restart of a specific labeled zone, but not of the entire system. Trusted Extensions also enhances the X11 server with a hard-coded MLS policy. However, the Trusted Extensions windowing system does provide some limited flexibility for the desktop MLS policy, as X11 applications are not consistent with regards to policy. Strict enforcement can be relaxed by explicitly granting specific windowing-system privileges to applications, to users, or to the entire system. RHEL5 LSPP does not include support for a multilevel X11 server nor support for multilevel user sessions. Thus, there is no support for desktop or management GUI when using the RHEL5 LSPP target evaluation. While Trusted Extensions policy might be considered inflexible because it is hard-coded in the kernel, RHEL5 LSPP policy flexibility comes at the cost of significant complexity. As of today, the SELinux MLS policy files [6] are tens of thousands of lines, which presents a significant source for error. So, one might ask what benefits are associated with this approach. Type enforcement is an expressive tool for hardening a system, but its features are not a requirement of any of the CC protection profiles against which these systems are being evaluated. On the contrary, type enforcement seems better suited to solving a very small set of specific problems other than multilevel security. Simpler methods than type enforcement are available to confine applications, such as those provided by the Novell AppArmor for Linux product or by the CA eTrust for UNIX software for the Solaris 10 OS. Several OpenSolaris projects [7] are actively pursuing opportunities and solutions to provide additional per-process controls for file and network access. File Systems One of the major features of Trusted Extensions is the ability to use any of the supported Solaris file systems without requiring modifications. File labels in Trusted Extensions are implicitly derived from zone labels, so no mount labels are needed. Similarly, Trusted Extensions eliminates the need for label-related mount options and extensions to the mount table as were needed by the Trusted Solaris 8 implementation. Administrators and customers are free to choose whatever file system or backup software meets their needs without concern about compatibility with their security requirements for labeling. Trusted Extensions uses NFS to share multilevel data when permissible, and it also provides MLS support for NFS clients and servers. Both Trusted Extensions and non-Trusted Extensions clients and servers can be used together in conformance with the MLS policy. A single Trusted Extensions NFS server can export multiple file systems, each at their own label. The Trusted Extensions NFS server code enforces the MLS policy for requests from single-level and multilevel hosts. The Trusted Extensions NFS client code enforces the MLS policy when mounting exported file systems from single-level hosts. RHEL5 LSPP requires customized versions of Linux file systems to associate security contexts with files and requires that the security context be specified for mounted file systems. The file systems are customized by extending the inode to include label information. Because of this strict requirement, new file systems and existing backup software must be specifically modified to support labels in order to work with RHEL5 LSPP. RHEL5 LSPP does not currently support a multilevel implementation of either an NFS client or server. Therefore, customers cannot use the common NFS protocol to share data easily within their data center. Device Allocation Both the RHEL5 and Trusted Extensions systems have support for device allocation, which permits writing to or reading from external devices. Trusted Extensions includes support for CD-ROM and diskette drives and USB devices. RHEL5 LSPP has support only for CD-ROM and diskette drives. Trusted Extensions also includes a GUI for managing the allocation and deallocation of external devices. RHEL5 LSPP has no equivalent GUI tool. Protecting Higher-Level File Names Trusted Extensions can offer an MLS file system policy that is simpler and more efficient than the one in RHEL5 LSPP, as well as providing more robust protection. No mechanism or user in a labeled zone can override the MLS file system policy. Even a root-owned process is constrained by the MLS policy. A lower-level process cannot determine the existence or the name of a higher-level file. The Trusted Extensions mount policy requires that all file systems mounted into a zone are dominated by the zone's sensitivity label. This means that no file system is writable at more than one label at a time. The policy is self defining based on the label's relationship to another. Sun holds a patent based on the automatic mounting of lower-labeled home directories in a read-only manner to higher-labeled zones. In RHEL5 LSPP, a process that has read-access to a directory can see the names of all files in that directory, including higher-level files. This situation contrasts with traditional MLS systems, such as Trusted Solaris and the SGI Trusted IRIX product. The kernel policy of traditional MLS systems can be configured to prevent upgraded file names from being read by a lower-level process. Previous LSPP evaluations have required that the evaluation target prevent a lower-level process from determining the existence of a higher-level file. The lack of this protection might prevent another evaluation target from passing this evaluation. Performance RHEL5 LSPP maintains an access vector cache (AVC) that records previous policy decisions and reduces some of the overhead of the policy. The Solaris OS needs no such cache because the privilege policy checks are simple bit comparisons.
Lmbench microbenchmark comparisons show that the overhead for SELinux file I/O operations is quite high (see "SELinux and grsecurity: A Case Study Comparing Linux Security Kernel Enhancements" [8]).
Trusted Extensions adds no overhead to file I/O operations because it
uses the unmodified, standard Solaris system calls, such as
Resource Management Since Trusted Extensions label isolation is implemented by using Solaris Zones, each label has resource controls beyond the normal MLS policies specified by LSPP. System resources, such as memory sets, CPUs, disk quotas, and network bandwidth, can be assigned based on sensitivity labels. For instance, a system administrator might dedicate a CPU or a percentage of a CPU to higher-level processes. RHEL5 LSPP has no comparable feature, so it is not possible to prioritize the use of resources based on the sensitivity of subjects and objects. Resource Polyinstantiation Versus Resource Sharing All resources in a labeled zone are polyinstantiated by default. The sharing of individual file systems is specified as part of the zone's configuration. Trusted Extensions is unique in that it also supports polyinstantiated network ports, which is described later in the Trusted Networking section. In RHEL5 LSPP, no resources are polyinstantiated by default. Rather, a configuration file enumerates the list of polyinstantiated directories and specifies whether the directories are polyinstantiated by user, by label, or both. RHEL5 LSPP does not support polyinstantiated network ports. Trusted Processes In Trusted Extensions, all the processes in the global zone are part of the Trusted Computing Base (TCB). Being part of the TCB does not mean that the process is exempt from the privilege policy; rather, it means that the process is cleared for all labels on the system. The underlying files accessed by the process are still protected by DAC. Objects owned by root are further protected by the privilege escalation policy. A non-root process must assert all privileges to override the DAC protections of root-owned objects. Access to the global zone is restricted, so normal users can interact only with global zone processes by means of Trusted Path interfaces, such as the Common Desktop Environment (CDE) window manager or the Sun Java Desktop System (Java DS) Panel Manager. The Solaris best practices encourage the use of roles rather than the root user to administer the system. By using roles in this way, you can use fine-grained privileges and rights profiles to ensure that the role cannot do purposeful or accidental damage to the system. Trusted Extensions uses Lightweight Directory Access Protocol (LDAP) to create a distributed TCB to share a single instance of the trusted networking and RBAC security policy configuration. By using distributed policies, a security administrator needs to manage this information only in one place rather than on each system in the distributed environment. Unlike Trusted Extensions, the RHEL5 LSPP policies are not
distributed, which can make the policies unwieldy to manage and to
scale when more systems are added. However, RHEL5 LSPP does have
the Security Context Transitions By default, both RHEL5 LSPP type enforcement and Trusted Extensions labeled zones provide strong isolation. In addition, RHEL5 LSPP provides a transition mechanism in which the execution of an application, such as Firefox, has the side-effect of transitioning the process to a new domain, somewhat like a set-GID executable. The Solaris OS has no equivalent feature to transition from one labeled zone to another, and therefore has no rules for such transitions. This is the most significant difference between the two MLS approaches. The Solaris OS does provide a security context transition that is based on process privileges. Each process has a permitted privilege set that is an upper bound to the set of privileges the process can dynamically manipulate. Policy-enforcing functions in the kernel and in the X server determine access based on the subject's effective privilege set. In addition, a global zone process can start processes in labeled zones that run with reduced privileges. Each process also has a limit privilege set that is an upper bound to the set of privileges that can be gained by executing a root-owned set-UID binary. In this case, the new process's effective set and permitted set are initially set to the limit set of the parent process. The limit privilege set can also be configured on a per-label basis. Thus, even root processes that run in labeled zones are constrained by the privilege policy. Trusted Extensions privileges are similar to the permissions that are specified by the RHEL5 LSPP policy files. Currently, RHEL5 LSPP has a significantly larger set of permissions and object classes than Trusted Extensions, although both systems are extensible. RHEL5 LSPP now supports over 50 object classes and hundreds of object permissions [9], each of which may be associated with an access decision. Trusted Extensions currently supports 10 privilege classes with a total of 67 privileges [10]. Label Specifications Both RHEL5 LSPP and Trusted Extensions define labels that consist of hierarchical and non-hierarchical components. SELinux refers to these as sensitivity and category, and the combination of the two comprise a level. Trusted Extensions refers to the hierarchical component as a classification, the non-hierarchical component as a compartment, and the combination as a sensitivity label. Trusted Extensions labeling conforms to the U.S. Department of Defense (DoD) specifications, which provide great flexibility in specifying labels. The label encoding specification enables a security administrator to create new labels in many ways. For instance, a security administrator can create three distinct labels using just two compartment bits. One label has the compartment 1 bit set, the second label has the compartment 2 bit set, and the third label has both the compartment 1 and 2 bits set. This specification also provides the ability to define relationships between categories. For example, a security administrator can specify mutually exclusive categories, specify required combinations, and define subcategories and inverse categories where the lack of a bit causes a name to be generated. User Authorizations An authorization is a set of attributes associated with Solaris users. Trusted programs interpret authorizations to determine whether a user is allowed to perform an operation. For example, a user might be authorized to print a job without explicit header and footer sensitivity labels. Trusted Extensions provides an extensible framework for enumerating and managing such authorizations as part of user rights management (RBAC). RHEL5 LSPP does not provide an equivalent framework. The object classes and permissions that are defined in the MLS policy configuration correspond to objects that are maintained by the kernel. These object classes and permissions are not oriented to policy decisions made by trusted applications and lack a framework for trusted applications to make policy based on individual user authorizations. Trusted Networking RHEL5 LSPP and Trusted Extensions provide multilevel networking support. Both systems support strategies for implicitly and explicitly labeling network packets, and the systems support the Commercial IP Security Options (CIPSO) to exchange multilevel packets. Each system provides a mechanism for associating implicit labels with single-level systems. Trusted Extensions supports CIPSO for IPv4 and IPv6, while RHEL5 LSPP supports only CIPSO for IPv4. Both Trusted Extensions and RHEL5 LSPP can use IPsec with multilevel networking. Trusted Extensions uses IPsec with CIPSO. RHEL5 LSPP has an additional multilevel networking capability where IPsec security associations can be used to convey security contexts. A similar capability is in development for Trusted Extensions. Trusted Extensions provides automatic network port polyinstantiation for
any network interface when the Both Trusted Extensions and RHEL5 LSPP provide configuration options to specify multilevel ports. Such ports can be used by trusted servers to accept requests at a range of labels. The Trusted Extensions configuration also allows explicit labels and ranges to be specified so that disjoint labels, which are outside of the range, can be included. This allows for a great deal of flexibility when it comes to allowing applications to communicate with each other and strictly with each other through disjoint labels. Both Trusted Extensions and RHEL5 LSPP provide APIs that can be used
by services to determine the label of the network peer. Trusted
Extensions provides uniform interfaces, the In RHEL5 LSPP, the similar Unlike Trusted Extensions, the RHEL5 LSPP target evaluation can only accept remote connections from systems that use explicit labeled networking protocols. Auditing and Policy Violations SELinux provides a permissive mode of policy interpretation in which
violations are permitted and are logged in the audit trail. The Trusted Extensions extends the Solaris auditing system by adding subject and object labels to audit events. Like the Solaris OS, the Trusted Extensions auditing system supports output in XML format. The extensive Trusted Extensions auditing also includes the auditing of events within the multilevel desktop environments. The Trusted Extensions audit trail records policy violations.
The The Solaris Management Console offers a set of graphical RBAC tools that associate the process privileges, user and group IDs, and authorizations required to perform the operations with rights profiles. These rights profiles are, in turn, assigned to users or roles, or they are assigned hierarchically to other rights profiles. RHEL5 LSPP does not include a comparable graphical RBAC-management tool. Multilevel Printing Both Trusted Extensions and RHEL5 systems support single-level and multilevel printing based on the Internet Printing Protocol (IPP) and PostScript Printer Description (PPD) files that generate appropriate output for PostScript printers. In addition, Trusted Extensions interprets RBAC authorizations when granting rights to override specific printing policies. For instance, Trusted Extensions has the ability to suppress the automatic labeling of printed output that is granted to authorized users. The authorization infrastructure is part of Solaris RBAC and has no equivalent in RHEL5 LSPP. Multilevel Desktop Environment A single-level or multilevel desktop environment enables users to use a windowing system to perform their day-to-day work. A single-level desktop permits users to work at a single label, while a multilevel desktop permits users to work at more than one label at which they are cleared. Trusted Extensions includes multilevel extensions to the Xorg server and to the Java DS (GNOME 2.6) and CDE environments. Both environments include the following features:
These multilevel desktop features are supported by workstations and by Sun Ray ultra-thin clients. Trusted Extensions also includes a single-level version of the Java Desktop System. RHEL5 LSPP does not include single-level or multilevel desktop support. Therefore, there is no way for end users to log in and see all their permitted data in one interface. The RHEL5 LSPP evaluation target is essentially never to be managed with a GUI. The CAPP, LSPP, and RBACPP protection profiles state that all data flows present in the evaluated system are subject to the required protections. Therefore, if your evaluation target includes data flows that do not implement security policy, those data flows must be disabled prior to evaluation. The version of the Solaris 10 11/06 OS that was submitted for LSPP evaluation includes both single-level and multilevel desktop environments. In addition, the single-level version of the Java DS has been included to meet Section 508 accessibility requirements. These Section 508 requirements are not part of the CC evaluation, but they are required for products sold to the U.S. Government. The RHEL5 LSPP system that was submitted for evaluation does not include single-level or multilevel windowing system components. As a result, the windowing system that is available with the Targeted policy configuration is not available when the MLS policy configuration is used. Thus, there is no way to use a GUI manager to simplify the policy of the RHEL5 LSPP evaluation target. Product Maturity Trusted Extensions was officially released as part of the Solaris 10 11/06 OS release on December 11, 2006. Although Trusted Extensions is a new product with a new architecture, it contains a significant body of code from the Trusted Solaris OS and has essentially all the features of its predecessor. Also with Trusted Extensions, Sun introduces its fourth-generation multilevel desktop environment, now based on open source GNOME. The previous multilevel desktop, which is based on CDE, is still provided. Trusted Extensions also extends the CC certified Process and User Rights Management models (privileges and authorizations) of the Solaris 10 OS, released in March 2005. The MLS policy for SELinux is still being developed and is planned for release with RHEL5. At this time, the documentation about the MLS policy configuration appears minimal and discourages use for general-purpose cases -- see Red Hat Enterprise Linux Deployment Guide, Section 43.6, Multi-Level Security (MLS) [12]. Rather, Red Hat encourages users to choose the simpler Targeted policy. The MLS policy configuration implements a significantly more complex solution for MLS and RBAC. Many type enforcement features of the MLS policy add complexity and overhead, which can make deploying RHEL5 LSPP more difficult and expensive than a comparable Trusted Extensions deployment. In most cases, Trusted Extensions has simpler and more efficient mechanisms to provide greater end-user functionality with less overhead and less administrative complexity. Trusted Extensions also offers excellent support and training opportunities, and it offers an extensive collection of high-quality documentation [13]. Many of the MLS policy configuration features, such as types, object classes, permissions, and transitions, do not correspond to LSPP requirements. Thus, these features are present for complicated security policy configuration, but they might not map well to real-world requirements for certification and use. ConclusionsWhile an SELinux policy can express the labeled information flows of a system, it often requires a very large and detailed policy. With Trusted Extensions, simply defining the labels and assigning user clearances is usually sufficient. The isolation and polyinstantiation features of Trusted Extensions provide both MLS and Multiple Independent Levels of Security (MILS), as described by the newer MILS protection profile. Therefore, Trusted Extensions might be able to achieve higher levels of assurance in the future. The isolation provided by labeled zones is more compatible with commercial, off-the-shelf software because it is more transparent to applications, and it is substantially easier to manage because it is a natural extension of the Solaris management model. Choose Trusted Extensions if you need to support users working at multiple levels and not just multilevel web services, because Trusted Extensions provides two multilevel desktop environments. RHEL5 LSPP does not provide a multilevel desktop environment. While RHEL5 LSPP appears to have a more integrated IPsec solution, Trusted Extensions has more multilevel functionality. For instance, Trusted Extensions enables a single host to act as a multilevel NFS server. RHEL5 LSPP does not support NFS file sharing. Thus, Trusted Extensions enables a security administrator to implement labeled security throughout the data center, in file sharing, in web hosting, in application firewalls, and for other uses. RHEL5 LSPP and Trusted Extensions have taken different design approaches to meet the same CC profiles. However, while these systems might meet the same criteria, it is important to consider the functionality that is included in the systems submitted for LSPP evaluation. Trusted Extensions includes several features, such as multilevel NFS and a multilevel windowing system, that are designed to meet the security data flow requirements specified by LSPP and to be usable in real-world environments and by real-world customers. Comparable features are either not available or have been excluded from the RHEL5 LSPP evaluation target. References
Unless otherwise licensed, code in all technical manuals herein (including articles, FAQs, samples) is provided under this License. |
 |
 | |