HP shows path to Linux for trusted Solaris customers
By Glenn Faden on Dec 03, 2006
HP has written a new white paper Legacy MLS/Trusted Systems and SELinux – concepts and comparisons to simplify migration and adoption . This paper does a great job of comparing the current SELinux development efforts with Sun's legacy Trusted Solaris product. However, it says nothing about Sun's current offering, Solaris Trusted Extensions. Considering the HP paper was published in August 2006, and that Sun announced that Trusted Extensions would replace Trusted Solaris more than a year ago, this is unfortunate. But the OpenSolaris download has only been available since July , and the complete set of manuals for Trusted Extensions have only been online since September. To help HP bring their article up-to-date, I am providing pointers to the latest information.
In HP shows path to Linux for trusted Solaris customers it is asserted that
SUN is forcing customers to move off of Trusted Solaris 8 with the end of support life this fall. SUN's solution requires significant porting to support Solaris 10 with Trusted Extensions since it's based on a new architecture.
First, Sun has announced no plans to end support of Trusted Solaris 8. Second, the effort to port from Trusted Solaris to Trusted Extensions is pretty minor when compared to a similar SELinux port. Sun has published Solaris Trusted Extensions Transition Guide which provides equivalent interfaces between the two systems.
I have included excerpts from section 11, Technical comparison: legacy MLS vs. SELinux. The subsection 11.1 Principle of least privilege does a good job of explaining the legacy MLS privilege model in Trusted Solaris 8. However, the new privilege implementation in Trusted Extensions is the same as that in Solaris 10, and doesn't depend on MLS.
One important distinction is that in traditional MLS systems a process is empowered with privilege but in SELinux, the domain is endowed with capabilities and attributes. This means that in SELinux a process's privilege is limited by the domain. Traditional MLS privileged processes have no bound on the scope of their privilege.
In Trusted Extensions, each domain is associated with a Solaris zone. A process's privileges in a zone is limited by the zone's privilege limit set, which is configurable on a per-zone basis. Even a root process in a labeled zone is subject to this limit.
11.2.1 MLS Privileges as a means to least privilege
Similarly, a process having the privilege file_mac_read is able to bypass Bell-LaPadula policy MAC controls to read any file.
The privileges file_mac_read and file_mac_write are obsolete and are not implemented in Trusted Extensions. The corresponding window system privileges, win_mac_read and win_mac_write, are not available in labeled zones, by default. Even a process with all privileges, such as a root process in the zone, cannot override the MAC policy specified for the zone.
2.2 Separate trusted and commercial versions
Any program that relied on the root user had to be modified to use privileges. Administration programs had to be modified to manage the new security features and new utilities had to be developed for security features that did not exist in the commercial systems. The end result was that the trusted version of the commercial release lagged commercial versions and it was impossible to stay current.
Since the privilege policy in Trusted Extensions is identical to that of the standard Solaris OS, there are no special requirements to customize applications, and the trusted version is now incorporated into the commericial release.
11.2.2 SELinux domain capabilities and attributes as a means to least privilege
Thus to accomplish tasks which cannot be done as a normal user, a process must be running as UID=0 and have SELinux policy rules to allow access.
Using the Apache web server as an example, the httpd process needs to run as the root user for several reasons. One reason is to spawn off child processes running with a different user identity. The policy for the Apache web server domain is assigned the Linux capability setuid to be able to do this. Thus the Apache web server is running with the root user id to pass the Linux kernel tests to set a different user id to a child process and the setuid capability is assigned to its domain to pass the SELinux policy test.
In Trusted Extensions, the Apache server does not need to run as root because it can be assigned the required proc_setid, via an RBAC or SMF policy file. This privilege cannot be abused to escalate its privilege set because it doesn't allow a transition to root.
The rules governing type enforcement are not overridden by the capabilities and/or attributes. Thus a process could only wreak havoc within a single domain in SELinux while a privileged process could wreak system-wide havoc in a traditional MLS system.
Similarly, in Trusted Extensions, an all-privileged process can only wreak havoc within its own zone.
However, the implementation is not complete as of the publication of this paper but it is expected to be finished in time for the release of Red Hat Enterprise Linux 5.
In Trusted Extensions, polyinstantiation is automatic and completely implemented..
In SELinux, audit records are used to determine what changes need to be made to the policy to allow an authorized program to accomplish its task. The policy rather than the program is modified.
The same is true in Trusted Extensions. The privilege specifications are part of the SMF and RBAC policies.
11.6 Trusted path
For a rogue program to masquerade as the login program, it would have to execute in a domain which had
access to device files used for login purposes. This circumstance would not exist in the rule base
Trusted Extensions reserves a portion of the screen for constant feedback so that the user can determine when a login prompt is trustworthy. Spoofing is not something that SELinix can prevent in a policy rule.
11.8 Trusted X Windows
Linux does not include an implementation of trusted X Windows
Trusted Extensions ships with a choice of multilevel CDE or GNOME desktops. Both are layered on the Trusted X11 server, which implements fine-grained MAC and DAC policies transparently. It interprets process privileges and labels for policy enforcement and audits all security-relevant events. Sun has contributed its implementation of trusted X Windows to X.org.