The policy is now being developed further to suite our solutions in permissive mode. Check out http://www.facebook.com/group.php?gid=72016920562

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. )

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

amin.

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.

amin.
]]> http://imsciences.edu.pk/serg/2007/08/tpm-hacks-controversial-security-paper-nixed-from-black-hat/feed/ 0 http://imsciences.edu.pk/serg/2007/07/ima-as-a-standalone-service/ http://imsciences.edu.pk/serg/2007/07/ima-as-a-standalone-service/#comments Sun, 22 Jul 2007 09:59:19 +0000 shazkhan http://securityengineering.wordpress.com/2007/07/22/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

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.

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.