MQP:Project Overview - Revision history

J: /* Project Schedule and Goals */

2008-09-19T18:25:13Z

‎Project Schedule and Goals

J: /* Project Schedule and Goals */

2008-09-19T17:03:40Z

‎Project Schedule and Goals

J: /* Project Schedule and Goals */

2008-09-19T14:54:04Z

‎Project Schedule and Goals

J: /* Project Schedule and Goals */

2008-09-19T13:19:12Z

‎Project Schedule and Goals

Jpolitz at 20:14, 15 September 2008

2008-09-15T20:14:42Z

Jpolitz at 19:59, 15 September 2008

2008-09-15T19:59:46Z

Jpolitz: /* Project Schedule and Goals */

2008-09-15T18:46:17Z

‎Project Schedule and Goals

J at 13:18, 15 September 2008

2008-09-15T13:18:24Z

J: /* Project Schedule and Goals */

2008-09-15T12:35:22Z

‎Project Schedule and Goals

J: /* Project Schedule and Goals */

2008-09-13T20:36:18Z

‎Project Schedule and Goals

@@ Line 59: / Line 59: @@
 [x] T13: Finish initial definition of Resource model
 [x] T14: Implement classes to support Resource model
-[1] T8: Find a conceptual way to represent analysis results to the developer
+[x] T8: Find a conceptual way to represent analysis results to the developer - see Resource Model
-[1] T10: Do research into runtime analysis, especially using the Java instrumentation package and determine if this is easy enough to become a priority task
+[1] T17: Define interfaces for interacting with the resource model
-[2] T17: Define interfaces for interacting with the resource model
+[1] T15: Connect Resource model to Permission Requirements model
-[2] T15: Connect Resource model to Permission Requirements model
+[1] T18: Create a mapping between a resource/action model and Java Permissions - partially done
-[2] 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
-[2] 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
-[2] 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
-[3] T23: Start developing tool for user interaction - either IDE or command line or custom GUI
+[2] T23: Start developing tool for user interaction - either IDE or command line or custom GUI
-[3] T20: Design a user interface for working with the resource model
 [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
 [ ] 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

@@ Line 59: / Line 59: @@
 [x] T13: Finish initial definition of Resource model
 [x] T14: Implement classes to support Resource model
-[1] T8: Find a way to represent analysis results to the developer - also choose IDE integration or standalone output or some combination
+[1] T8: Find a conceptual way to represent analysis results to the developer
 [1] T10: Do research into runtime analysis, especially using the Java instrumentation package and determine if this is easy enough to become a priority task
 [2] T17: Define interfaces for interacting with the resource model
@@ Line 65: / Line 65: @@
 [2] T18: Create a mapping between a resource/action model and Java Permissions - partially done
 [2] T22: Be able to import mapping into the resource/action model
-[2] T9: Develop a way for the user to interact with the tool - either IDE or command line or custom GUI
+[2] T9: Develop a way for the user to interact with the tool into more formal idea
 [3] T20: Design a user interface for working with the resource model
 [3] T19: Be able to translate between the resource model and the Permission model and policy grants and back

@@ Line 59: / Line 59: @@
 [x] T13: Finish initial definition of Resource model
 [x] T14: Implement classes to support Resource model
 [1] T8: Find a way to represent analysis results to the developer - also choose IDE integration or standalone output or some combination
 [1] T10: Do research into runtime analysis, especially using the Java instrumentation package and determine if this is easy enough to become a priority task
 [2] T17: Define interfaces for interacting with the resource model
 [2] T18: Create a mapping between a resource/action model and Java Permissions - partially done
-[2] T19: Be able to translate between the resource model and the Permission model and policy grants and back
+[2] T22: Be able to import mapping into the resource/action model
-[2] T7: Populate our model with outside policy sources
 [2] T9: Develop a way for the user to interact with the tool - either IDE or command line or custom GUI
 [3] T20: Design a user interface for working with the resource model
 [ ] 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

@@ Line 57: / Line 57: @@
 :Low priority, possibly won't be finished
 <tasks>
-[1] T13: Finish initial definition of Resource model
+[x] T13: Finish initial definition of Resource model
-[1] T14: Implement classes to support Resource model
+[x] T14: Implement classes to support Resource model
 [1] T15: Connect Resource model to Permission Requirements model
 [1] T8: Find a way to represent analysis results to the developer - also choose IDE integration or standalone output or some combination
 [1] T10: Do research into runtime analysis, especially using the Java instrumentation package and determine if this is easy enough to become a priority task
 [2] T17: Define interfaces for interacting with the resource model
-[2] T18: Create a mapping between a resource/action model and Java Permissions
+[2] T18: Create a mapping between a resource/action model and Java Permissions - partially done
 [2] T19: Be able to translate between the resource model and the Permission model and policy grants and back
 [2] T7: Populate our model with outside policy sources

@@ Line 3: / Line 3: @@
 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.
 ==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.

@@ Line 1: / Line 1: @@
 [[Category:MQP]]
 {{MQP:Navbar}}
-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 assist the developer create and test Java policy.  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.  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.
+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.
 ==Program Analysis==

@@ Line 1: / Line 1: @@
 [[Category:MQP]]
 {{MQP:Navbar}}
-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.
+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 assist the developer create and test Java policy.  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.  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==
@@ Line 13: / Line 13: @@
 *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.

@@ Line 66: / Line 66: @@
 [ ] 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
 [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>

@@ Line 53: / Line 53: @@
 :Low priority, possibly won't be finished
 <tasks>
-[1] T1: Finalize Static Analysis Algorithm
+[1] T13: Finish initial definition of Resource model
-[1] T2: Finish designing and implementing the model to store permissions data
+[1] T14: Implement classes to support Resource model
-[1] T3: Use static analysis algorithm to populate model
+[1] T15: Connect Resource model to Permission Requirements model
-[1] T4: Determine if memory constraints will affect the static analysis tool significantly
+[1] T8: Find a way to represent analysis results to the developer - also choose IDE integration or standalone output or some combination
-[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] T10: Do research into runtime analysis, especially using the Java instrumentation package and determine if this is easy enough to become a priority task
-[1] T6: Find other methods to optimize call graph creation
+[2] T4: Determine if memory constraints will affect the static analysis tool significantly
 [2] T7: Populate our model with outside policy sources
 [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
+[ ] T12: Prune the call graph created by Soot to avoid excessive permission requirements produced by conservative calculation of virtual calls
-[3] T11: Determine if Static Analysis Algorithm is suitable for dynamic updates.  As code changes, a minimal amount of data would be regenerated
+[ ] T6: Find other methods to optimize call graph creation - See T12
 </tasks>