Trusted what?

This is a response to an open letter from Darren Moffat to IBM. While this open letter has very little substance and is almost entirely opinion there are some things I’d like to address.

Thanks for trying to bring Mandatory Access Control out of its “hiding place” in the military and trying to put it to use where we really need it in health care.

Why thank you, we in SELinux land have been working on this for quite some time, of course the inclusion of SELinux into a mainstream Linux distribution (enabled by default) was one of the driving forces behind this. Trusted Solaris (and its Trusted cousins) focused on military Mandatory Access Control and therefore were never able to approach the mainstream. You�ll note that there is a difference between the Mandatory Access Control for military and Mandatory Access Control for every one else, I’ll address this later.

However, personally, I don’t think SE Linux is the correct solution for this.

Any particular reason for this? I�d love to hear some actual technical reasons for this opinion, in the mean time I�ll supply some technical reasons why SELinux is the correct solution (at the bottom).

Why not work with partner, Sun Microsystems, and use a Common Criteria EAL4+ (CAPP, RBACPP and LSPP) certified system: Trusted Solaris

You mean the end-of-lifed Trusted Solaris? I think anyone who is forward looking probably wants something that will be supported for a while.

or better yet our up and comming Solaris Trusted Extensions that layers on top of the award winning Solaris 10.

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.

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)

A solution that is known to work and has been developed and deployed in mission critical environments for over 15 years.

Except that Trusted Extensions is very different from Trusted Solaris, and once again, there is a difference between military MAC and commercial MAC.

Now, aside from the specific responses above here are my more general responses:

The main issue here is that the security goals of this project are can not be met by Trusted Extensions. Trusted Solaris isn’t an option since its end-of-lifed.

Without talking about this project specifically a primary security goal for commercial applications of MAC is integrity rather than confidentiality. Even in the medical industry the applications manage the data, and the data is not organized into hierarchical levels. The applications, therefore, have to be trusted to manage the data correctly. The security goal, then, is to maintain the integrity of the applications. The way this is accomplished in SELinux is to put the application into a protected domain that only authorized applications can access (including over network resources).

In a hypothetical multi-tiered architecture the applications would be managed by an agent that is controlled centrally. The applications may have different data or differing levels of access and therefore need to be seperated. Not only does this allow the applications to have different permissions but also prevents the applications from interfering with one another. The agent would have the ability to manage the applications and their configuration files. The applications shouldn’t be able to modify their own or other applications configuration files. Additionally unrelated applications on the system should also not be able to compromise the integrity of the applications or the agent.

In SELinux the policy could be configured to tightly control the interaction between the agent and the applications. The applications should only able to read their configuration and talk to the backend servers over the network. The applications could be isolated from one another and have specific network resources (e.g., this specific application can talk to this backend database on this interface and this port). The most important part is that both the agent and the applications must be protected from the rest of the system. That means even if someone is able to compromise another service running on the machine the applications (and the data) is protected (short of a kernel exploit).

Now, in the context of Trusted Extensions; the agent and applications would have to be in different zones to maintain separation. This leads to problems though since the agent running in one zone would be unable to write application configuration files or otherwise manage the applications. 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 second is to put the application servers into zones and leave the agent in the global zone (the one that has access to all zones). This, however, prevents the agent from being confined in any way.

This brings up the bigger concern. The global zone is effectively unconstrained. Any service running in it can affect all the other zones. 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).

Next, Trusted Solaris has a long lineage in military MAC. For the uninitiated this means MLS (Multi Level Security). The MLS security model closely resembles the actual “real life” policies of the military and therefore was sufficient for their purposes. This security model implements a hierarchal set of levels that represent different levels of confidentiality (think secret, top secret, unclassified, etc). Trusted Extensions builds on this lineage by using zones for course grained sensitivity levels.

This, however, does not address the need for integrity. Since the global zone is unconstrained, that is, it is considered ‘trusted’ there is no way to make any claims about the integrity of any app running in any zone. With SELinux even ‘trusted’ apps are confined to only the privileges they need to do their job. As an example, the passwd command must be ‘trusted’ to violate the security model on MLS systems since it needs to read and write ‘up’ to the password file. When something is trusted in MLS it has practically no constraints on what it can do, since the policy is so limited and inflexible. 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.

Without Trusted Extensions ability to 1) define fine grained access vectors between the applications, and 2) protect the agent from the applications and 3) protect the integrity of the applications, even from ‘trusted’ applications it cannot meet the typical security goals of architectures like this.

The ability of Type Enforcement to define fine grained access for the entire system and allow controlled interactions between them makes it a very powerful MAC system that can be used in a number of different environments. MLS has a legacy of being used for military/government systems (and will continue use there, as it is useful for that particular environment) but it cannot be applied to most environments outside of the military.