Clarifying Some Misconceptions About Trusted Extensions
By Glenn Faden on Oct 10, 2006
Solaris Trusted Extensions is in beta, not well tested, not present in any released (and supported) Solaris and also has not been evaluated (http://niap.nist.gov/cc-scheme/vpl/vpl_type.html#operatingsystem ).
Solaris 10 is currently under evaluation for CAPP and RBACPP (http://niap.nist.gov/cc-scheme/in_evaluation.html#s ) and has apparently not started LSPP. SELinux, on the other hand, has been released in at least 2 commercially supported distributions (Red Hat and Engarde), and in several community supported distributions. Red Hat has EAL4+ in CAPP and is currently in evaluation for LSPP and RBACPP. SELinux is pretty far ahead of Solaris and Trusted Extensions with regard to evaluations.
Since Red Hat has not yet released any system that supports an MLS policy, it seems presumptuous to assume that the RHEL5 evaluation is ahead of Trusted Extensions. Having been through six evaluations, I know you can't predict how long these evaluations will last.
There are also some fundamental changes between the Trusted Extensions implementation and Trusted Solaris. Since Trusted Extensions has abandoned fine grained labels in favor of labeled zones it is difficult to specify specific interactions applications running in different zones can have on one another, more on this later. (This is my understanding of Trusted Extensions, please correct me if I'm wrong).
Since zones are course grained and the only way for them to interact with one another is over network sockets this architecture is not possible.
One might be tempted to do one of 2 things. The first is to put the agent and the applications in the same zone. This breaks the security goal since application servers can then interfere with the agent and the other applications. There is no way to separate any part of the architecture and you've gained very little (if anything).
The global zone is effectively unconstrained. Any service running in it can affect all the other zones.
Furthermore, in Trusted Extensions, port polyinstantiation and namespace isolation prevent the global zone services from interacting with non-global zone clients unless explictly specified as multilevel services.
This in itself violates the security goal since the applications (whether they are in their own zones or not) have no integrity assurance. An exploit of any application running in the global zone can affect the applications (and therefore the data).
In SELinux the passwd command is allowed to write to the password file but it can't, for example, write to user home directories or use raw devices or use the network. This level of granularity for confining trusted applications is necessary to ensure integrity of any application running on the system.
There is always a trade-off in the design of any system. Clearly SELinux provides additional controls that are not available in Trusted Extensions. The Trusted Extensions team learned from its experience with Trusted Solaris that simplicity is an essential component of security. With that understanding, we used a straight-forward approach to provide strong mandatory controls while minimizing complexity and overhead.