MQP:Project Overview

From JimboWiki
Jump to: navigation, search


MQP Navigation

The goal of this project is to encourage developers to create applications that use the security manager and to create models of security that make the Java security standard more understandable and usable. This project will attempt to develop methods to analyze and describe 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 analysis, runtime analysis, and developer input 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. High-level models of security will allow for a logical understanding of the security requirements of a program independent of specific security mechanisms. 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, descriptions of policy abstracted from the Java security model, and instances where a developer's security goals may conflict with code permission specifications.

Security Resource Model

The Java security model uses run-time checking of Permissions against developer or environment defined policy files to perform access control. These Permission objects represent a checkpoint for the code to perform certain low-level actions like read a file or get access to runtime properties of the system. While developers do need to implement checks of permissions in code sometimes, oftentimes the actual permission checks are contained within library code and the developer only needs to know what permissions need to be granted to the application. In most cases, security concerns can be addressed in terms at a higher-level than Permission objects represent. In this project, we will design and implement a high-level model that is more usable for developers in defining relevant areas or security, including resources and the actions performed on them. This high-level model will relate to permissions that need to be granted to the application, without the developer necessarily needing to understand the mechanism that implements the policy. See the description of the Resource Model here.

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

Developer Input

The developer should be able to give their own view of the expected policy requirements of the system. This should be done in a vocabulary that is familiar to the developer. A "resource centric" approach is probably the most appropriate for this.

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> [x] T13: Finish initial definition of Resource model [x] T14: Implement classes to support Resource model [x] T8: Find a conceptual way to represent analysis results to the developer - see Resource Model [1] T17: Define interfaces for interacting with the resource model [1] T15: Connect Resource model to Permission Requirements model [1] T18: Create a mapping between a resource/action model and Java Permissions - partially done [1] T22: Be able to import mapping into the resource/action model [1] T9: Develop a way for the user to interact with the tool into more formal idea [1] T20: Design a user interface for working with the resource model [2] T23: Start developing tool for user interaction - either IDE or command line or custom GUI [3] T19: Be able to translate between the resource model and the Permission model and policy grants and back [3] T7: Populate our model with outside policy sources [3] T10: Do research into runtime analysis, especially using the Java instrumentation package and determine if this is easy enough to become a priority task [ ] T21: If time and other restrictions allow, implement runtime analysis and combine the results with static analysis [ ] T4: Determine if memory constraints will affect the static analysis tool significantly [ ] T5: Determine if it is possible to store the analysis of library code temporarily or permanently to reduce compute time and memory usage [ ] T12: Prune the call graph created by Soot to avoid excessive permission requirements produced by conservative calculation of virtual calls [ ] T6: Find other methods to optimize call graph creation - See T12 [ ] T16: Create a runtime analysis tool - See T10 [ ] T11: Determine if Static Analysis Algorithm is suitable for dynamic updates. As code changes, a minimal amount of data would be regenerated [ ] T17: Do performance optimizations on the static analysis tool to make it run significantly faster, and without wasting memory [x] T1: Finalize Static Analysis Algorithm - See Prototype 1 [x] T2: Finish designing and implementing the model to store permissions data - See Prototype 1 [x] T3: Use static analysis algorithm to populate model - See Prototype 1 </tasks>