« Slides for Solaris... | Main | More Clarifications:... »
Tuesday Oct 10, 2006

Clarifying Some Misconceptions About Trusted Extensions

On May 23, Joshua Brindle posted a reply to an open letter written by one my colleagues, Darren Moffat . In that reply entitled  Trusted What? there were several statements made about Trusted Extensions that are apparently misunderstandings. Rather than trying to squeeze my reply into the comment window in his blog, I decided to post a more more complete reply here, and create a link from his blog to mine. For contextual purposes I have copied portions of his posting.


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.
Solaris and Trusted Solaris have been continuously evaluated for more than a dozen years. The Solaris 10 GA evaluation is nearly complete, and Solaris 10 11/06, which includes Trusted Extensions, is currently in evaluation using the same EAL4+ assurance level and the same protection profiles as RHEL5. However, the Trusted Extensions evaluation includes additional end-user functionality such as multilevel windowing and NFS.

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).
Actually, the new architecture makes it easier to specify such interactions. For example, the zone configuration includes an enumeration of multilevel ports and the label ranges or disjoint label sets for which they are effective. In addition, the zone configuration includes the directories which may be shared via LOFS or NFS. The kernel guarantees that all such mounts are consistent with the MAC policy, rather than requiring the operator to specify mount labels.

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.
In addition to network sockets, Trusted Extensions supports one-way FIFOs, and reading down to lower-level zones via LOFS and NFS.

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).
In Solaris 10, the Service Management Facility, smf(5) provides this separation. The process credentials of each service (uid, gid, and minimum privileges) and its related authorizations are specified in a manifiest for each service. See smf_security(5) and rbac(5). Neither the service nor the administrator need to run as root; they have distinct identities and credentials.

The global zone is effectively unconstrained. Any service running in it can affect all the other zones.
This is a misunderstanding. Processes in the global zone are constrained by their privileges just as processes in labeled zones. For example, a global zone process cannot observe non-global zone processes unless it has been granted the proc_zone privilege. It can further be constrained by the proc_info privilege. Similarly, the files belonging to zones are inaccessable unless the file_dac_search privilege is granted.

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).
This is also untrue. No file is writable in more than one zone. Files in the global zone have the highest integrity. Files exported from the global zone are always read-only.

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.
Root is not exempt from the privilege policy in Solaris 10, so a root process that can update /etc/shadow is not necessarily privileged to write to a user's home directory (file_dac_write) nor use raw_devices (sys_devices, or net_rawaccess). Furthermore, Solaris 10 introduced the concept of basic privileges. These are privileges that can be removed from processes to make them weaker than traditional unprivileged processes. Although there is currently no basic privilege to prevent a process from accessing the network, such functionality is planned for a future release.

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.

Posted at 08:05PM Oct 10, 2006 by gfaden in Sun  |  Comments[4]

Comments:

Please add that Sun can indemify government users of Trusted Extensions in Solaris against potential claims against their intellectual property - and Red Hat, given that they do not own their own intellectual property, cannot offer this protection to customers - which as best I understand, is a violation of FARS.

This is why Red Hat includes language to this effect in the Risk Factors portion of their SEC filings. For government users, this is an absolute imperative - and Red Hat has begun losing momentum due to their avoidance of the issue.

Posted by Anonymous on October 10, 2006 at 08:47 PM PDT #

I think you missed some of Josh's points (disclaimer - I am a friend of Josh's).

1) Concerning fine-grained labeling:
I believe Josh's point was that you didn't have fine-grained labeling on files. And using a loopback filesystem (bind mount to us Linux users) or network filesystem is a hack that becomes necessary when you don't have this sort of per-file labeling.

2) Conscerning constraining the global zone: Josh's point was that the global zone wasn't constrained by the zone infrastructure. I realize that all processes (even those in the global zone) are constrained by privileges (seem to be analogous to capabilities in the Linux world), but from what I can tell these are coarse-grained privileges that are not bound to a particular object (please correct me if I'm wrong). So, as soon as a privileged process needs to write one file it doesn't own, you grant it file_dac_write and it can write to any file it doesn't own. This is why you need per-file labeling (which TSOL had) to begin with. Privileges are not sufficient.

Anyway, I think the main point here is that Trusted Extensions != Trusted Solaris. They are quite different. I applaud you guys for figuring out a way to get MAC out of a one-off product and useable with your mainstream product. But people who are used to Trusted Solaris should not think Trusted Extensions are the same thing. As you pointed out, you had to make trade-offs in security capabilities to make the system simpler. So, system developers need to examine those tradeoffs closely before making a decision about their platform of choice.

Posted by Chad Sellers on October 11, 2006 at 07:15 AM PDT #

I'm not going to counter this (as I said on my blog) except to note that 1) when I wrote my blog it was absolutely accurate, TX had not entered any evaluations, let alone LSPP which RH has been in for well over a year and 2) it might be easier to write an accurate article (though there were no technical errors, only differences in opinion on the usefullness of certain things) if TX could actually be downloaded and tried out, which AFAIK isn't available to the public still. So it seems like I was totally right for saying in May the British Gov was right to choose SELinux over TX.

Posted by Joshua Brindle on October 13, 2006 at 05:15 AM PDT #

Josh is correct with respect to item (1). TX didn't enter evaluation until about a month after he wrote his blog entry. It was announced on June 27 in the following OpenSolaris URL: News , but Sun didn't make a formal press release until September. With respect to item (2), TX became available about a month after his initial blog. In fact, my first blog entry, on June 15, was an announcement of its availability to the public. You can still download the free OpenSolaris version from Distributions . I'm not going to discuss our customers in this blog.

Posted by Glenn Faden on October 13, 2006 at 12:25 PM PDT #

Post a Comment:
  • HTML Syntax: NOT allowed