MQP:Project Overview
|
The goal of this project is to encourage developers to create applications that use the security manager 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 structure and build a tool to help developers create applications that 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.
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 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 happen as the developer writes code - similar to the 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 File Generation
With all the policy information in the tool, it would be possible to generate some sort of standardized text-based policy file.
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.
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
<tasks> [1] Add dates and priorities to all these goals [1] Finish this list [ ] Finalize Static Analysis Algorithm [ ] Determine if Static Analysis Algorithm is suitable for dynamic updates (regenerating as little of the security data as possible when code changes) [ ] Finish designing the data structure to store permissions data [ ] Find a way to represent analysis results to the developer [ ] Do research into runtime analysis, especially using the Java instrumentation package [ ] Do research into IDE integration </tasks>
