“Applications that Enforce System Security”

[These are comments to the paper titled, "From Trusted to Secure: Building and Executing Applications That Enforce System Security" available at USENIX ATC'07.]

The paper deals with the issue of differences between security enforcement on the operating system level and within applications. It describes a mechanism through which security labels of a MAC mechanism from the OS can be communicated to the application; the application provides assurance that it enforces the security policies within its logic; the output of information from the application is also communicated to the OS MAC mechanism to ensure that these outputs get the correct labels.

Things to notice:

The architecture relies on security typed languages (Jif to be specific) to ensure that no illegal information flow can occur within the application
The architecture provides an interface through which OS policies can be communicated to and from the application
It provides a mechanism which provides assurance that the policies of the OS are being implemented correctly and
It uses a high level policy to describe “declassifiers” — interfaces which are allowed to move information from high level of security to a lower level.

I found the last point of particular importance because it explained to me exactly what PRIMA meant by ‘interfaces which convert data of low integrity to high integrity’.

Another important point to note is that the information flow analysis to and from the application is not static (as in Jif - which uses compile time checks only, as far as I know) but dynamic in that the lattice of principals is created at runtime (meaning that mappings of labels to and from the OS would occur at runtime thus depending on the OS policy at runtime).

The developer does not have to know these mappings either. They are defined in a separate high-level policy so that they can be defined by the system administrator on the target machine.

The concept of mappings is particularly clarified through Figure 6 and the fifth paragraph in Section 4.3. The policy within the appplication allows pub -> siic -> sec. pub is mapped to security level s0 of the OS and sec to s1. Information can thus from from s0 to s1 (but only if this is allowed by the OS!) The Jif Runtime takes care of this sort of information flow.

Future directions of my interest:

policy compliance analysis between application policy and OS policy.
declassifier generalization (although the authors themselves have pointed out a few works in this direction).
issues of attestation of the architecture. (I believe this is not so straight forward due to the inter-linkages between different modules of the architecture but then, attestation is never easy anyway. )

Tuesday, June 17th, 2008 Ideas, SELinux, Trusted Computing

2 Comments to “Applications that Enforce System Security”

I am really interested to know how they are handling OS and application specific policies i.e. enforce the union or whatever. What do you think about the policy simulation idea? Its similar to theirs but a bit trivial for serious use Its just going to demonstrate info flows possible or unwanted info flow detection but not much querying flexibility.