Security Engineering Research Group

“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:

1. policy compliance analysis between application policy and OS policy.
2. declassifier generalization (although the authors themselves have pointed out a few works in this direction).
3. 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. )

ARM links with Trusted Logic for secure mobiles, set tops

ARM Ltd. has teamed with Trusted Logic to develop secure software for mobile handsets and set-top boxes that will combine the microprocessor core maker’s TrustZone technology with optimized security software from Trusted Logic…..

Embedded.com - ARM links with Trusted Logic for secure mobiles, set tops:

amin.

Needs of network for MAC

After the comparison of trendy MAC enhancements, I have been figuring out the general needs of a network for MAC. We have three places where MAC can and is enforced:

1. In Application: Where flow control of application is controled by labeling the data of the application. Current research is limited to MLS becuase its simple. And because the security type languages are not mature enough to handle the granularity. I have seen two framworks at this level, which make use of these languages. One of them has been partially integerated with selinux by using the application layer API to selinuxfs. I am curious why they are so interested in JAVA! There is no C extension.
2. On Application Layer: This is achieved for applications that do not use TCP/IP directly. They use RPCs so the common network controls cannot handle properly. The reason is that port to application mapping is done by portmapper daemon. Thus the rpc headers carry the security contexts. Such applications are NFS and NIS.
3. At TCP/IP Layer: Here the ports are labeled for the associated applications on both sides. I a hostile environment this would not prove useful so encryption would also be required. This is achieved by IPSEC associations being labeled. I am not fully satisfied by the mechanisms at this level because at one extreme we have lack of security and on the other hand manageability issues.

LDAP is on the todo list but nothing is currently being done about it upto my knowledge. The todo list also wants more granularity and API at TCP/IP layer.

Policy distribution being a great issue has no solid solutions yet. The only possibility to till now is a tranlation server, which would provide an equivalence mehanism for internode security contexts. But this is has been left as an idea and no progress is being made. IPSEC associations were provided only for subjects but currently they are working for providing object support but the work is hidden yet. They are thinking for CIFS support as well. Ephimeral ports can be handled with standard SELinux API for applications.

The biggest problem with distributed policy is the type enforcement, which is part of the security model/context. Leaving it out would be a solution but will affect greatly because code bindings will be lost, which will result in loss of integrity control. The context has three main models. User identity, role and TE. If one is lost it will affect the others because they are tied together to help each other. I am figuring out how much affect will be made. At the same time integrity can be measured with IMA and alike. I would like comments on what you ppl think about the differences in the integrity model of TE and IMA.

If anyone can come up with other ideas of network needs plz brainstorm so I figure out the requirements. There are others which I have’nt mentioned because they are trusted applications by SELinux. I find a gap over here because trusting applications is not a good idea. Information flows can work here. More on this when I get a solid insight on them.

What do you guys think should be my next target. Amin is sorting out to integerate his study with all this. So give ideas of possibilities. Any of you who thinks their work can have relevance plz share your findings so that we can be more useful to each other.

TPM HACKS-Controversial Security Paper Nixed From Black Hat!

IMA as a standalone service

The following paras are from the linux mailing list which is a mail sent by ibm ima team. They are working out this userspace ima thingy. I am still not satisfied. Mr. TAT can you plz verify it? I can email u the patches and the related mails as well. 

This is a request for comments for a subset of the original integrity
patches. By submitting this subset of the original patches, we hope to
simplify its review and ultimately ease its inclusion into the kernel.
For this reason, neither EVM nor SLIM are included in this patchset.
This patchset contains: Linux Integrity Module(LIM), Integrity
Measurement Architecture (IMA), and patches to the TPM driver. The LIM
patch defines 3 integrity API calls, 7 integrity hooks, placement of
the hooks, and a dummy integrity service provider. There are very minor
changes from the previous release.  The IMA patch is now an independent
integrity service provider, which provides support for a subset of the
integrity API calls.

IBAC, a sample LSM module, which helps clarify the interaction between
LSM and LIM modules, will be posted separately to the LSM mailing list.
In addition, we are working on an SELinux integrity patch to take
advantage of the integrity services, in a similar way to the IBAC
example.

Patch 1/3 integrity: Linux Integrity Module (LIM)
Patch 2/3 integrity: IMA as a stand alone integrity service provider
Patch 3/3 integrity: TPM internal kernel interface

Mimi Zohar
Dave Safford

TPM Manager for Linux released!

Ruhr-University Bochum and Sirrix AG have developed an open source application providing an easy to use graphical user interface to manage and configure a Trusted Platform Module (TPM).

The TPM Manager can be used on PC systems equipped with a TPM that is supported by the Linux kernel. Users of such systems can now easily check the capabilities of their TPM, read out public keys and certificates, or change the TPM settings like, e.g., disable or activate it.

The TPM Manager is currently available for Linux only, but should be easily portable to other operating systems providing a TSS API. The source code of the TPM Manager is available on SourceForge at [1] and licensed under GPL. We (Ruhr-University Bochum and Sirrix AG ) appreciate feedback from users who like to give it a try. Users will also find help and support on the Trusted Computing Forum at [2].

[1] http://sourceforge.net/projects/tpmmanager/
[2] http://forum.emscb.org

amin.

Slim, EVM and TPM (3.2.0)

Follow this link  for a simple idea. Further it has a link to ibm research page. This link metions an old study but this page will be updated.

Let me know what you ppl think of it. It is a more updated approach than IMA. And it is a loadable userspace module! Mr. MMA will like it.

Sir Mr. MMA I am waiting for your coments regarding IPSec article by Joshua.

An EBook

`This is an old but nice book regarding Trusted System and Computer Security. One can appreciate the author’s clear ideas and imagination about the subject.

http://nucia.unomaha.edu/library/gasserbook.pdf

TPM Emulator

Mr. TAT was installing and configuring TPM emulator. It would not run because of some driver initialization problem. I was thinking if it make sense, do we need to install tpm drivers? I mean maybe the emulator does not include drivers. Although it had some /dev/tpm and tpmd entries but we can try this for a change.

But I wish it has been sorted out by now.  MarioStrasser seems to be weak at troubleshooting his own designs!

The Practical Part Starts Now

As soon as I am over with Recluze, I am going to start working with IPSec and SELinux now that my literature survey is complete (I think so). Next I plan to get some help from MR. MMA to let me in on his findings regarding how to stack IMA on SELinux.

I personally think using TPM’s PCR will be another good thing instead of IMA because IMA has more then I need. But according to Mr. MMA its very problematic. Sir have you tried to copy the technique IMA uses to address PCR.

Side by side I am trying to understand the functionality of the Tresys’ Policy Management Server and the module support it provides for policies because I am looking forward to incorporate it for ditributed MAC implementation.

One thing that confuses me, this is for Mr TAT and Mr. MMA, can we skip DAC if we use MAC? Is MAC’s use enough for OS requirements?

If we could just have a few more people we could start adjusting applications for MAC implementations! Its also a good idea for BSc/BCS projects. We could also move towards LDAP NIS etc.