Glenn Faden's Blog

  • December 2, 2006

Comparing SELinux with Solaris Trusted Extensions

Guest Author

I am frequently asked to compare Solaris Trusted Extensions to SELinux. Although this seems like a simple question, it is hard to make a fair comparison because the goals of each system are different. I am not an expert on SELinux but there is quite a lot of information on the Web. One of the best sites I have found is The UnOffical SELinux FAQ

Solaris Trusted Extensions is just a configuration of Solaris, so it is best to start there. Like all modern operating systems, Solaris is highly configurable. Policy is configured in multiple ways in multiple databases, but there are two primary mechanisms. Most user-based policy is defined via the Role-Based Access Control (RBAC) databases. Most service-based policy is defined using the Service Management Facility (SMF). Both frameworks leverage process rights management (privileges) which are interpreted by the kernel to grant or deny access to protected resources. The privilege policy is extensible but is always enforced. While the Solaris policy is abstracted via policy hooks, Sun only provides a single set of policy functions which rely on the privilege mechanism exclusively. Most of these functions are contained in a single file policy.c .

Compared to the Linux Security Modules (LSM) framework, the Solaris implementation is not optimized to be extended or replaced. Sun could have easily delivered these functions in a loadable module, as was done in  the original implementation in Trusted Solaris 8. However, experience with Trusted Solaris showed that multiple policy implementations were difficult to support. Therefore, the Solaris kernel always enforces policy based on process privileges; there is no mechanism for loading alternate policies nor disabling the privilege policy.

In contrast LSM is all about policy extensibility. Multiple polices can be loaded simultaneously, of which SELinux is just one example. The policy enforcement can be disabled, or set to permissive or enforcing modes. The policies associated with SELinux are described in a policy language and are compiled and loaded into the kernel. There is so much flexibility that defining policy is the biggest obstacle to deploying SELinux. Red Hat discusses this issue in Discussion of Policies where they explain why they have Targeted, Strict, and MLS policies.

So rather than comparing all of SELinx to Solaris Trusted Extensions, it makes more sense to compare the MLS policies of the two systems. Both systems are designed to meet the same evaluation criteria, EAL4+/LSPP , but the implementations are radically different. Trusted Extensions adds security labels to  Solaris Containers (zones) while SELinux extends Type Enforcement to support labels as an additional field in the security context.

Although the general rules for information flow are similar in both systems, the same trade-off in simplicity vs. flexibility applies to multilevel polices. SELinux provides MLS labels at the same granularity as other Type Enforcement rules. MLS policies must be defined for applications, directories, services and network ports.

On the other hand, Trusted Extensions derives most MLS subject and object labels from zone associations. Since zones provide a completely virtualized environment, applications in labeled zones run without modification. There is no need for new filesystem attributes like multilevel directories to resolve naming conflicts. Labeling policies for file sharing, networking, and windowing automatically conform to  the MLS policies.

In some respects, the zones policy is more robust than that of the strict SELinux policy. For example, the labels within a zone are fixed. There are no interfaces to transition the label of a subject, or object within the zone. Even a process with all privileges in a labeled zone is subject to the MLS policy. The MLS label and privilege limits for each zone are specified by global zone administrative roles and cannot be changed while the zone is running.

When comparing these systems, one must consider the design goals. As Red Hat states on its polices page, the MLS policy for it upcoming RHEL5 is designed for servers only. Solaris Trusted Extensions was designed to provide multilevel environments for end users as well as services. So ease-of-use was was built into the security policy.

The Trusted CDE system was ported to Trusted Extensions from Trusted Solaris 8, and has been available through OpenSolaris since July. The upcoming build 54 will also include an alternative trusted desktop, Trusted Java Desktop System , based on GNOME 2.16.

We are very close to the first commercial release of Solaris Trusted Extensions. It will be delivered as part of Solaris 10 11/06  in  about two weeks. It will include Trusted CDE and a version of Trusted JDS based on GNOME 2.6.

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.