Difference between revisions of "MQP:Static Analysis Strategies"

Revision as of 20:26, 26 August 2008

Overview

This page summarizes some of our discussions on strategies for performing static analysis to infer permissions.

Goals

The best tool that we envision would be able to infer the permissions required at each program point. Showing this level of detail would give a developer the best chance to understand the security requirements of code. With this analysis, it would be simple to accomplish our more baseline objective, that of inferring the permissions required by an application at each method and class. This would be the minimum required to create a policy file that granted the needed permissions to the code. From either analysis, we would need to store the security data in an intermediate format to easily inform a dynamic or run time analysis at a later time. This format could also aid in the construction of policy files for the application.

Baseline Analysis

The methods we are considering for the baseline analysis are based on using graph searching algorithms on a call graph of the application. The general strategy is to find the points where checkPermission is called in the program, and traverse the graph against the direction of method invocation. That is, each method that could call the method containing the checkPermission call would be traversed. At each of these points, the method would be marked as requiring that permission and then all methods that invoke it would be recursively traverse in the same fashion.

There are a few special cases and stopping conditions for this algorithm. First, if a node (method) is reached in the graph and it is already marked with the set of permissions that need to be added, the current branch of the graph traversal can stop. Second, the doPrivileged() operator is a stopping condition as well, as it indicates that the code it annotates is responsible for encapsulating the current security context. Third, when a Thread object is passed to a different context, it needs to reflect that the context constructing the Thread requires the current set of permissions. These are general descriptions of the strategies and need to be formalized more. They are also based on some observations from Larry Koved's paper.

Deep Analysis

The deep analysis would provide a more detailed view of the permissions required by inferring the permissions at each program point. For example, it may be possible to show that a certain permission will be required only if a certain branch of an if statement is taken. This would normally not affect the policy file or permissions required by the application, as it is assumed that both branches of the if statement would execute at some point. However, this could be quite a useful tool for developers, who would be able to see what parts of their code they could move or edit to better encapsulate or understand the security requirements of a program.

To do this, the analysis would follow a similar pattern as the baseline analysis, with the exception of looking at special code blocks or groups of statements, like if-else blocks. Where there is a branching operations, the different blocks could be marked as needing different sets of permissions. While the method containing these blocks would still require all of the permissions contained within, it would be possible to see which parts of the method use the required permissions.

More?

As the project continues, we may continue to consider different types of analysis with further goals in mind.