MQP:Project Overview
|
The goal of this project is to encourage developers to create applications that use the security manager and to make creating such an application significantly easier by providing a tool to analyze Java policy. This project will attempt to develop methods to analyze the policy requirements of a Java application and methods of presenting the results to developers. These methods will be used to design and build a tool to help developers create applications that properly utilize Java security policy. Analysis may use a combination of static and runtime analysis tools to create a complete representation. Outside sources, such as policies that are already in place, developer specified policy requirements, and other policy sources, may be used to enhance the analysis. Results of the analysis may be presented through an IDE, a generated policy file, or some standalone representation. Results include effects of policy, policy misuse, and places where the program is likely to fail due to improperly specified permissions.
Program Analysis
The tool produced should be able to take input from multiple sources to perform a detailed analysis of the permission requirements of each part of the code.
Static Analysis
Static Analysis can be used to provide a significant amount of information about the permission requirements of an application. More information is available here
Runtime Analysis
In order to demonstrate, test, and further refine the policy proposed by static analysis, runtime analysis is required. There are several strategies for runtime analysis such as:
- An interactive policy development centered approach, where the developer (or some administrator) is prompted to allow or deny permission calls as they come up
- A monitoring centered approach, where all permissions are simply granted and recorded
- A testing centered approach, where only failures or special watch cases are presented for action
Combining Results
Combining results from multiple sources allows us to present a more complete representation of the actual requirements and implications of an application's security design. With the combined data source, analyses are able to build on what others have already learned. The combined result can show new insights into the the application's security requirements.
Result Presentation
In order to communicate the results of the analysis to the developer, it is important to have a clear, concise representation of the application's permission requirements.
IDE
The most usable representation within an IDE would cause analysis to run automatically as the developer writes code - similar to a live syntax checker. This may not provide enough time to perform the static analysis that would take place. Another concern is keeping the permission requirement set up to date as the coder continues to write code without regenerating the entire data set.
It would also be possible to have analysis data presented after a user requests a full analysis - similar to a code coverage tool. This would require user intervention to perform.
The sort of information to be presented in an IDE includes:
- All permissions required for some block of code (class, method, etc) and the source path of each permission requirement
- Occurrences of doPrivileged blocks
- Occurrences of Thread objects being passed outside their own context
- Exceptions handled in different contexts
Policy Export
With all the policy information in the tool, it would be possible to generate some sort of external policy representation, such as a text file list of permissions.
Standalone Tool
A standalone tool could provide some customized representation to show analysis results in any format. This could be some sort of query engine, possibly tied to a GUI or report generator.
Usability Concerns
Ease of Use
Ideally, the tool should not require any user intervention at all. Static analysis could be run in the background while code is being written, assuming the analysis algorithm doesn't require too much computing resources.
Intrusiveness
It is important that the tool does not infringe on the developer's current workflow. The tool should not get in the developer's way, or prevent the developer from doing anything. There should always be a way to override what the tool would do automatically - for instance, the developer should be able to override any policy the tool suggests. The tool should also avoid doing complex tasks without user intervention.
Speed of Analysis
The analysis should be fast, so that developers are encouraged to use the tool.
Presentation of Data
Data presentation should be complete, but not overwhelming. Providing too much data would waste the developer's time sorting through useless stuff. Providing too little would make the tool useless. It will be important to determine exactly what data is useful and how to present it in a compact and efficient form.
Project Schedule and Goals
- Priority 1
- Finish this week
- Priority 2
- Finish next week
- Priority 3
- Finish in 2 or more weeks
- No priority
- Low priority, possibly won't be finished
<tasks> [1] T1: Finalize Static Analysis Algorithm [1] T2: Finish designing and implementing the model to store permissions data [1] T3: Use static analysis algorithm to populate model [1] T4: Determine if memory constraints will affect the static analysis tool significantly [1] T5: Determine if it is possible to store the analysis of library code temporarily or permanently to reduce compute time and memory usage [1] T6: Find other methods to optimize call graph creation [2] T7: Populate our model with outside policy sources [2] T8: Find a way to represent analysis results to the developer - also choose IDE integration or standalone output or some combination [2] T9: Find and develop a way for the user to interact with the tool - either IDE or command line or custom GUI [2] T10: Do research into runtime analysis, especially using the Java instrumentation package [3] T11: Determine if Static Analysis Algorithm is suitable for dynamic updates. As code changes, a minimal amount of data would be regenerated </tasks>
