JimboWiki - User contributions [en]

MQP:Paper Outline

2008-10-30T18:21:18Z

Jpolitz: New page: *Introduction *Problem Description **Introduction to Java Security **Challenges in using Java Security **Other approaches to security? *Methods **Static Analysis ***Goals ***Algorithm **...

*Introduction

*Problem Description
**Introduction to Java Security
**Challenges in using Java Security
**Other approaches to security?

*Methods
**Static Analysis
***Goals
***Algorithm
****Koved's algorithm for Java 1.2
****Extensions and refinements
*****Threads
*****doPrivileged
****Basic Data Flow Analysis
***Implementation
****Soot
*****Call graph generation
*****Type analysis
*****Data flow analysis
****Analysis Class Structure
***Limitations of static analysis data
**Action Centric Model
***Goals
***Design
****Resources
*****Groups of actions
****Actions
*****Action Definitions
*****Filled Actions
****Rules
*****Rule Definitions
*****Filled Rules
*****Rules and permissions
****Action to rule translation
***Implementation
****Action Model Class Structure
****XML Specification of Definitions
****NetBeans Tool

*Results
**Static Analysis
***Successes
****Permission information
****Summary of permission requirements
***Limitations
****Call graph generation
****Runtime type identification
****Runtime parameter identification
**Action Centric Model
***Successes
****Representation of high-level model
****Independence from security implementation?
****Ease of development
***Extensions
****Model
*****Parameterized Resources
*****Actions Containing Actions
****Tool
*****Integration with Static Analysis
*****Use for application deployment
******Creation of real policy files
*****Storage of policies
*****User interface improvement

*Conclusions
**Helpfulness of identifying permissions
***Low-level view of security
***Specificity of results
**Utility of Action Centric security model
***High-level model
***Separation of model and security implementation

MQP:Main

2008-10-30T17:40:54Z

Jpolitz:

This project will attempt to devise a method for determining the appropriate permission set for an application written in Java and create a developer tool implementing the method.

See the [[MQP:Project Overview|Project Overview]] for more.
{{MQP:Navbar}}

==Paper==
*[[MQP:Paper Outline|Paper Outline]]

==Research Topics==
*[[MQP:Static Analysis Tools|Static Analysis Tools]]
**[[MQP:More on Soot|More on Soot]]
*[[MQP:Java Security|Java Security]]

==Design Topics==
*[[MQP:Static Analysis Strategies|Static Analysis Strategies]]
**[[MQP: A Thread Example|A Thread Example]]
*[[MQP:Security Analysis Data Structure|Security Analysis Data Model]]
*[[MQP:Introduction to Netbeans Integration|Introduction to Netbeans Integration]]
*[[MQP:Rule to Resource Mapping|Rule to Resource Mapping]]
**[[MQP:Mapping Back From Permissions|Mapping Back From Permissions]]
*Tool Design
**[[MQP:Tool Use Cases|Use Cases]]

==Proofs of Concept==
*[[MQP:Static Analysis Tool 0.1|Static Analysis Tool 0.1]]
*[[MQP:Resource Model Proof of Concept 0.1|Resource Model Proof of Concept 0.1]]

==The Team==
*[[Special:Emailuser/J|James Cialdea]] - WPI Class of 2009
**Computer Science Major
**Computer Engineering Minor
*[[Special:Emailuser/jpolitz|Joe Politz]] - WPI Class of 2009
**Computer Science Major
**Mathematics Minor
*A few WPI Advisors
*A few Sun Microsystems Project Sponsors

[[Category:MQP]]

MQP:Mapping Back From Permissions

2008-09-30T21:03:15Z

Jpolitz: /* Getting Action Parameters From Permission Rules */

{{MQP:Navbar}}
[[Category:MQP-Design]]

==The Goal==

One goal of the Resource Model is to be able to easily translate between the model and security implementations. In the context of Java, this primarily involves being able to translate between Permission type rules and actions. This involves a few steps, which include determining which Permission rules are required by each type of action, and how the arguments in Permission rules relate to the parameters in the actions.

==Getting Action Parameters From Permission Rules==

To determine the action parameters found in a given permission rule, the process is slightly more complicated than the process of substituting the action parameters into the correct places in the rule parameter. For example, the template for a SocketPermission rule application may look like this (with action parameter names found between matching {}):

completehost = "{hostname}:[{portrange}]"
action = "connect"

And a given instance of a SocketPermission may look like this:

completehost = "*.example.org:[8000-8080]"
action = "connect"

In this example, the case is fairly straightforward. Regular expressions can be used on the template for completehost to find which parts are variables and which parts are not. Then these in between strings can be used to find which parts of the rule parameter refer to which variables. The result of doing a backwards mapping would result in a FilledActionDefinition referring to the ActionDefinition for "SocketConnect", with ActionParameters hostname="*.example.org" portrange="8000-8080".

==Sets of Permission Rules Defining One Action==

In other cases, a given action, for example the "GetAndAlterClassLoader" action, requires several Permission rules to be represented in the Java security framework. In this case, when an initial set of Permission rules is given, it needs to be found if any subset of those filled in rule definitions match all the rule applications for each given action. The actions that have complete matches are fully represented by the permission rules, and the ones that have incomplete matches are suggested by the permission rules.

MQP:Mapping Back From Permissions

2008-09-30T21:02:49Z

Jpolitz: New page: {{MQP:Navbar}} Category:MQP-Design ==The Goal== One goal of the Resource Model is to be able to easily translate between the model and security implementations. In the context of Ja...

{{MQP:Navbar}}
[[Category:MQP-Design]]

==The Goal==

One goal of the Resource Model is to be able to easily translate between the model and security implementations. In the context of Java, this primarily involves being able to translate between Permission type rules and actions. This involves a few steps, which include determining which Permission rules are required by each type of action, and how the arguments in Permission rules relate to the parameters in the actions.

==Getting Action Parameters From Permission Rules==

To determine the action parameters found in a given permission rule, the process is slightly more complicated than the process of substituting the action parameters into the correct places in the rule parameter. For example, the template for a SocketPermission rule application may look like this (with action parameter names found between matching {}):

completehost = "{hostname}:[{portrange}]"
action = "connect"

And a given instance of a SocketPermission may look like this:

completehost = "*.example.org:[8000-8080]"
action = "connect"

In this example, the case is fairly straightforward. Regular expressions can be used on the template for completehost to find which parts are variables and which parts are not. Then these in between strings can be used to find which parts of the rule parameter refer to which variables. The result of doing a backwards mapping would result in a FilledActionDefinition referring to the ActionDefinition for "SocketConnect", with ActionParameters hostname="*.example.org* portrange="8000-8080".

==Sets of Permission Rules Defining One Action==

In other cases, a given action, for example the "GetAndAlterClassLoader" action, requires several Permission rules to be represented in the Java security framework. In this case, when an initial set of Permission rules is given, it needs to be found if any subset of those filled in rule definitions match all the rule applications for each given action. The actions that have complete matches are fully represented by the permission rules, and the ones that have incomplete matches are suggested by the permission rules.

MQP:Main

2008-09-30T20:50:29Z

Jpolitz: /* Design Topics */

This project will attempt to devise a method for determining the appropriate permission set for an application written in Java and create a developer tool implementing the method.

See the [[MQP:Project Overview|Project Overview]] for more.
{{MQP:Navbar}}

==Research Topics==
*[[MQP:Static Analysis Tools|Static Analysis Tools]]
**[[MQP:More on Soot|More on Soot]]
*[[MQP:Java Security|Java Security]]

==Design Topics==
*[[MQP:Static Analysis Strategies|Static Analysis Strategies]]
**[[MQP: A Thread Example|A Thread Example]]
*[[MQP:Security Analysis Data Structure|Security Analysis Data Model]]
*[[MQP:Introduction to Netbeans Integration|Introduction to Netbeans Integration]]
*[[MQP:Rule to Resource Mapping|Rule to Resource Mapping]]
**[[MQP:Mapping Back From Permissions|Mapping Back From Permissions]]

==Proofs of Concept==
*[[MQP:Static Analysis Tool 0.1|Static Analysis Tool 0.1]]
*[[MQP:Resource Model Proof of Concept 0.1|Resource Model Proof of Concept 0.1]]

==The Team==
*[[Special:Emailuser/J|James Cialdea]] - WPI Class of 2009
**Computer Science Major
**Computer Engineering Minor
*[[Special:Emailuser/jpolitz|Joe Politz]] - WPI Class of 2009
**Computer Science Major
**Mathematics Minor
*A few WPI Advisors
*A few Sun Microsystems Project Sponsors

[[Category:MQP]]

MQP:Main

2008-09-30T20:50:18Z

Jpolitz:

This project will attempt to devise a method for determining the appropriate permission set for an application written in Java and create a developer tool implementing the method.

See the [[MQP:Project Overview|Project Overview]] for more.
{{MQP:Navbar}}

==Research Topics==
*[[MQP:Static Analysis Tools|Static Analysis Tools]]
**[[MQP:More on Soot|More on Soot]]
*[[MQP:Java Security|Java Security]]

==Design Topics==
*[[MQP:Static Analysis Strategies|Static Analysis Strategies]]
**[[MQP: A Thread Example|A Thread Example]]
*[[MQP:Security Analysis Data Structure|Security Analysis Data Model]]
*[[MQP:Introduction to Netbeans Integration|Introduction to Netbeans Integration]]
*[[MQP:Rule to Resource Mapping|Rule to Resource Mapping]]
**[[MQP:Mapping Back From Permissions|Mapping Back From Permissions]

==Proofs of Concept==
*[[MQP:Static Analysis Tool 0.1|Static Analysis Tool 0.1]]
*[[MQP:Resource Model Proof of Concept 0.1|Resource Model Proof of Concept 0.1]]

==The Team==
*[[Special:Emailuser/J|James Cialdea]] - WPI Class of 2009
**Computer Science Major
**Computer Engineering Minor
*[[Special:Emailuser/jpolitz|Joe Politz]] - WPI Class of 2009
**Computer Science Major
**Mathematics Minor
*A few WPI Advisors
*A few Sun Microsystems Project Sponsors

[[Category:MQP]]

MQP:Rule to Resource Mapping

2008-09-26T18:08:23Z

Jpolitz: /* Java Classes */

[[Category:MQP-Design]]
{{MQP:Navbar}}
When developers are building their software, they have a fairly complete knowledge about what protected resources their application will require for certain actions, but may not have a full understanding about how to create a security policy from this data. In order to simplify the creation of policy, the policy could be defined in the resource and action centric vocabulary that the developer is familiar with, rather than the permission centric vocabulary of Java policy. The resource requirements the developer specifies could then be mapped into actual permission requirements.

==Resources==
There are a number of broadly-defined resource categories that programs could need to access and which need to be secure:

*File system
*Connection resources (Socket connections, for example)
*Java security system
*MBean functionality
*Java class loaders
*Media output (AWT graphics and sound)
*Authentication services
*Java runtime system management (including properties, environment variables)
*Java reflection

For each resource, there are actions associated. For instance:
*File-system
**Create, read, write, execute, and delete particular files
*Connections (socket and other)
**Listen, accept, and connect
**Handle cookies and other sensitive data
*Java system management
**Read specific properties
**Set properties
**Override default behaviors, like System.in/out, default exception handlers, shutdown hooks
*Media Output
**Control/monitor/produce AWT events
**Produce audio output
**Manipulate default applet behavior
*Class loaders
**Create new class loaders
**Load classes
**Get class loaders from certain security contexts
**Dynamically load libraries
*Java reflection system
**Access private methods
**Create reflected objects
*Java security system
**Get/set/alter SecurityManager
**Create AccessControlContexts
**Get/set/alter current Policies
**Get/set/alter authorization information from Principals
*MBean functionality
**Load classes in an MBean
**Perform trusted operations with an MBean
*Authentication Services
**Delegate authority to another subject
**Authorize grants to particular subjects
**Perform user authentication

A security system needs to somehow be configured to allow or deny these kinds of actions. In this model, the security system would apply some set of "rules" to subjects attempting to perform actions. There could be a number of different types of rules and mechanisms for implementing them. For most of the purposes of this project, the Java security system is considered, which uses Permission objects as its "rules."

In Java, to perform any of these actions, the application needs to be granted some set of permissions. They may not be all the same type (for example, permissions to perform actions on the security system can be RuntimePermissions or SecurityPermissions), and may have different parameters depending on the context the action is performed in (the host and port of a socket connection, for instance). This model allows the specification of high-level capabilities a program needs, to be followed by the mapping of the capable actions into actual Permission grants.

Each resource will have a different model of the actions that can be performed on or with the resource. This allows a more detailed specification of the capabilities a program needs. For example, Java system management actions could be parameterized with some set of properties that the program will need, and the file system actions can be parameterized with the areas of the file system that are of importance to the program.

It is an important point of this model that it is not dependent on the mechanism of Permissions in particular. The resource-action model is designed to be flexible, with the ability to parameterize actions allowing the model to map to different kinds of security implementations.

==Rules==
A rule represents a mechanism for enforcing security constraints on certain actions or resources. A rule can have certain parameters associated with it, which would have relationships with the parameters of relevant actions. For example, an action that has to do with reading the file system may have parameters describing what set of files is to be read by the currently running code. An associated rule for Permissions in Java may use these parameters to describe a particular instantiation of a FilePermission object with parameters like "/directory/specified/*" and "read".

==Permissions==
This project is concerned in particular with the Java security system, so understanding how the mechanism of Permissions work is important. Permissions can be interpreted as a kind of rule that fits into the resource-action model, allowing the model to directly relate to Java security.

Permissions have a low-level representation based on the classes they originate from, such as:
*java.io.FilePermission
*java.net.SocketPermission
*java.util.PropertyPermission
*java.lang.RuntimePermission
*java.awt.AWTPermission
*java.net.NetPermission
*java.lang.ReflectPermission
*and others

Some permission classes cover multiple resources and many actions. Some actions have multiple specific permission rules required.

==Mapping from Resources to Rules and Back==

Some sort of description of the relationship between a resource with its actions and rules would be developed. Important things to explain in this model include:
*A description of the resource and all its actions
*What rules relate to the resource's actions, and what parameters will cause these actions to be allowed or denied
*What actions of this resource will be allowed implicitly as a result of other actions, which are not necessarily associated with this resource, to be allowed

Given a set of resource requirements, we should be able to generate a rule set (and a permission set, in the case of using permission rules). Given a rule set, we should be able to do reverse lookups to find the resource grant implications.

===Resource to Rule Data Model===
The current resource model follows. Goals of the model were to be easy to traverse, and simple to represent in a text file, such as XML, allowing us to extend the model to other permission classes, such as those that are application specific.

*'''Resource''' - Top level container for a Resource (one for each resource present)
**'''Description''' - A human readable description of what the resource is (one for each resource present)
**'''Actions''' - A container for all the actions a resource has (one for each resource present)
***'''Action''' - Container for information about a specific action (many for each resource present)
****'''Description''' - A human readable description of what the action is (one for each action present)
****'''Action Parameters''' - A container for parameters to actions
*****'''Action Parameter''' - An Action can be parameterized in certain ways (for example, a read action in the file system may have an associated directory or filename)
****'''Rules to Apply''' - A container of rules to apply to allow this action (one for each action present)
*****'''Applied Rule''' - A description of a security rule requirement for this action and parameters (many for each rule container)
*'''Rule''' - Top level container for a Rule (one for each Rule present)
**'''Description''' - A human readable description of what the permission is (one for each permission present)
**'''Type''' - The type of the rule. For instance, in the Java security standard, the type is Permission.
**'''Name''' - The name of the rule. This is a unique identifier within each rule type.
**'''Field''' - A place to specify additional information about the rule. For example, with Permissions, this is where the class name of the particular permission is stored
**'''Parameters''' - A container for parameters to specify the rule
***'''Parameter''' - A description of the parameter (many per parameters container)
****'''Description''' - A human readable description of what the parameter is (one for each parameter present)
****'''Type''' - The type of the parameter

==Fitting Developer Specified Resources Together with Permission Requirement Analysis==
This resource requirement model fits in nicely with the idea of "Management Level Policy Requirements", and can use the same classes for its representation. Using this representation also allows us to compare the permission set caused by developer suggested resources to our own analysis of permission requirements. We would be able to detect unused permissions and missing grants, as well as overly vague grants.

==Model Implementation==
===XML Description===
The rule and resource mapping is persisted in an XML file.

The xml schema document specifies a structure similar to the one described above. It is available [http://www.jimbodude.net/xml/resourcetorules.xsd here] for now, though this may change.

Instances documents of this schema describe particular cases of resources and actions mapping to rules. A fragment of what a resource and action look like is shown here:

<pre>
...
<resource name="JVM Runtime Resources">
...
<action name="GetEnvironmentVariables">
<description>
Represents getting JVM environment variables.
</description>
<actionParameters>
<actionParameter name="varName">
<description> The name of the environment variable </description>
</actionParameter>
</actionParameters>

<appliedRules>
<appliedRule type="Permission" name="RuntimePermission">
<parameterApplications>
<parameterApplication name="name" value="getenv.{varName}">
</parameterApplication>
</parameterApplications>
</appliedRule>
</appliedRules>
</action>
...
</pre>

And this is what the rule for RuntimePermissions looks like:

<pre>
<rule type="Permission" name="RuntimePermission">
<field name="classname">java.lang.RuntimePermission</field>
<description>
Permission used for many different actions at runtime. Parameter is the name of
the named permission.
</description>
<parameters>
<parameter id="1" name="name"/>
</parameters>
</rule>
</pre>

In this case, the resource in question is certain JVM runtime actions and resources, and the particular action is getting access to environment variables. This action has a parameter, the name of the environment variable to access. It also has one rule application, an instance of the "Permission" type rule named "RuntimePermission." This rule needs to have values applied to its one parameter, "name". In this case, the parameter "name" is set to the value "getenv.{varName}". The syntax "{varName}" is a reference to the varName action parameter. Several instances of the GetEnvironmentVariable action could be specified, each with different parameterizations, that would lead to different instances of the RuntimePermission rule with different parameters.

===Java Classes===

This is slightly out of sync with the newer version of the model.

[[Image:ResourceModel.png|frame|Resource Model]]

MQP:Rule to Resource Mapping

2008-09-26T17:58:59Z

Jpolitz: /* XML Description */

MQP:Rule to Resource Mapping

2008-09-26T17:43:07Z

Jpolitz:

[[Category:MQP-Design]]
{{MQP:Navbar}}
When developers are building their software, they have a fairly complete knowledge about what protected resources their application will require for certain actions, but may not have a full understanding about how to create a security policy from this data. In order to simplify the creation of policy, the policy could be defined in the resource and action centric vocabulary that the developer is familiar with, rather than the permission centric vocabulary of Java policy. The resource requirements the developer specifies could then be mapped into actual permission requirements.

==Resources==
There are a number of broadly-defined resource categories that programs could need to access and which need to be secure:

*File system
*Connection resources (Socket connections, for example)
*Java security system
*MBean functionality
*Java class loaders
*Media output (AWT graphics and sound)
*Authentication services
*Java runtime system management (including properties, environment variables)
*Java reflection

For each resource, there are actions associated. For instance:
*File-system
**Create, read, write, execute, and delete particular files
*Connections (socket and other)
**Listen, accept, and connect
**Handle cookies and other sensitive data
*Java system management
**Read specific properties
**Set properties
**Override default behaviors, like System.in/out, default exception handlers, shutdown hooks
*Media Output
**Control/monitor/produce AWT events
**Produce audio output
**Manipulate default applet behavior
*Class loaders
**Create new class loaders
**Load classes
**Get class loaders from certain security contexts
**Dynamically load libraries
*Java reflection system
**Access private methods
**Create reflected objects
*Java security system
**Get/set/alter SecurityManager
**Create AccessControlContexts
**Get/set/alter current Policies
**Get/set/alter authorization information from Principals
*MBean functionality
**Load classes in an MBean
**Perform trusted operations with an MBean
*Authentication Services
**Delegate authority to another subject
**Authorize grants to particular subjects
**Perform user authentication

A security system needs to somehow be configured to allow or deny these kinds of actions. In this model, the security system would apply some set of "rules" to subjects attempting to perform actions. There could be a number of different types of rules and mechanisms for implementing them. For most of the purposes of this project, the Java security system is considered, which uses Permission objects as its "rules."

In Java, to perform any of these actions, the application needs to be granted some set of permissions. They may not be all the same type (for example, permissions to perform actions on the security system can be RuntimePermissions or SecurityPermissions), and may have different parameters depending on the context the action is performed in (the host and port of a socket connection, for instance). This model allows the specification of high-level capabilities a program needs, to be followed by the mapping of the capable actions into actual Permission grants.

Each resource will have a different model of the actions that can be performed on or with the resource. This allows a more detailed specification of the capabilities a program needs. For example, Java system management actions could be parameterized with some set of properties that the program will need, and the file system actions can be parameterized with the areas of the file system that are of importance to the program.

It is an important point of this model that it is not dependent on the mechanism of Permissions in particular. The resource-action model is designed to be flexible, with the ability to parameterize actions allowing the model to map to different kinds of security implementations.

==Rules==
A rule represents a mechanism for enforcing security constraints on certain actions or resources. A rule can have certain parameters associated with it, which would have relationships with the parameters of relevant actions. For example, an action that has to do with reading the file system may have parameters describing what set of files is to be read by the currently running code. An associated rule for Permissions in Java may use these parameters to describe a particular instantiation of a FilePermission object with parameters like "/directory/specified/*" and "read".

==Permissions==
This project is concerned in particular with the Java security system, so understanding how the mechanism of Permissions work is important. Permissions can be interpreted as a kind of rule that fits into the resource-action model, allowing the model to directly relate to Java security.

Permissions have a low-level representation based on the classes they originate from, such as:
*java.io.FilePermission
*java.net.SocketPermission
*java.util.PropertyPermission
*java.lang.RuntimePermission
*java.awt.AWTPermission
*java.net.NetPermission
*java.lang.ReflectPermission
*and others

Some permission classes cover multiple resources and many actions. Some actions have multiple specific permission rules required.

==Mapping from Resources to Rules and Back==

Some sort of description of the relationship between a resource with its actions and rules would be developed. Important things to explain in this model include:
*A description of the resource and all its actions
*What rules relate to the resource's actions, and what parameters will cause these actions to be allowed or denied
*What actions of this resource will be allowed implicitly as a result of other actions, which are not necessarily associated with this resource, to be allowed

Given a set of resource requirements, we should be able to generate a rule set (and a permission set, in the case of using permission rules). Given a rule set, we should be able to do reverse lookups to find the resource grant implications.

===Resource to Rule Data Model===
The current resource model follows. Goals of the model were to be easy to traverse, and simple to represent in a text file, such as XML, allowing us to extend the model to other permission classes, such as those that are application specific.

*'''Resource''' - Top level container for a Resource (one for each resource present)
**'''Description''' - A human readable description of what the resource is (one for each resource present)
**'''Actions''' - A container for all the actions a resource has (one for each resource present)
***'''Action''' - Container for information about a specific action (many for each resource present)
****'''Description''' - A human readable description of what the action is (one for each action present)
****'''Action Parameters''' - A container for parameters to actions
*****'''Action Parameter''' - An Action can be parameterized in certain ways (for example, a read action in the file system may have an associated directory or filename)
****'''Rules to Apply''' - A container of rules to apply to allow this action (one for each action present)
*****'''Applied Rule''' - A description of a security rule requirement for this action and parameters (many for each rule container)
*'''Rule''' - Top level container for a Rule (one for each Rule present)
**'''Description''' - A human readable description of what the permission is (one for each permission present)
**'''Type''' - The type of the rule. For instance, in the Java security standard, the type is Permission.
**'''Name''' - The name of the rule. This is a unique identifier within each rule type.
**'''Field''' - A place to specify additional information about the rule. For example, with Permissions, this is where the class name of the particular permission is stored
**'''Parameters''' - A container for parameters to specify the rule
***'''Parameter''' - A description of the parameter (many per parameters container)
****'''Description''' - A human readable description of what the parameter is (one for each parameter present)
****'''Type''' - The type of the parameter

==Fitting Developer Specified Resources Together with Permission Requirement Analysis==
This resource requirement model fits in nicely with the idea of "Management Level Policy Requirements", and can use the same classes for its representation. Using this representation also allows us to compare the permission set caused by developer suggested resources to our own analysis of permission requirements. We would be able to detect unused permissions and missing grants, as well as overly vague grants.

==Model Implementation==
===XML Description===
The permission and resource mapping is persisted in an XML file. (more description to come)

===Java Classes===

[[Image:ResourceModel.png|frame|Resource Model]]

MQP:Main

2008-09-26T17:26:21Z

Jpolitz:

This project will attempt to devise a method for determining the appropriate permission set for an application written in Java and create a developer tool implementing the method.

See the [[MQP:Project Overview|Project Overview]] for more.
{{MQP:Navbar}}

==Research Topics==
*[[MQP:Static Analysis Tools|Static Analysis Tools]]
**[[MQP:More on Soot|More on Soot]]
*[[MQP:Java Security|Java Security]]

==Design Topics==
*[[MQP:Static Analysis Strategies|Static Analysis Strategies]]
**[[MQP: A Thread Example|A Thread Example]]
*[[MQP:Security Analysis Data Structure|Security Analysis Data Model]]
*[[MQP:Introduction to Netbeans Integration|Introduction to Netbeans Integration]]
*[[MQP:Rule to Resource Mapping|Rule to Resource Mapping]]

==Proofs of Concept==
*[[MQP:Static Analysis Tool 0.1|Static Analysis Tool 0.1]]
*[[MQP:Resource Model Proof of Concept 0.1|Resource Model Proof of Concept 0.1]]

==The Team==
*[[Special:Emailuser/J|James Cialdea]] - WPI Class of 2009
**Computer Science Major
**Computer Engineering Minor
*[[Special:Emailuser/jpolitz|Joe Politz]] - WPI Class of 2009
**Computer Science Major
**Mathematics Minor
*A few WPI Advisors
*A few Sun Microsystems Project Sponsors

[[Category:MQP]]

MQP:Rule to Resource Mapping

2008-09-26T17:25:46Z

Jpolitz: MQP:Permission to Resource Mapping moved to MQP:Rule to Resource Mapping: We map to rules now, not permissions.

MQP:Permission to Resource Mapping

2008-09-26T17:25:46Z

Jpolitz: MQP:Permission to Resource Mapping moved to MQP:Rule to Resource Mapping: We map to rules now, not permissions.

#REDIRECT [[MQP:Rule to Resource Mapping]]

MQP:Rule to Resource Mapping

2008-09-26T17:21:48Z

Jpolitz: /* Resource to Permission Data Model */

MQP:Resource Model Proof of Concept 0.1

2008-09-26T04:18:45Z

Jpolitz:

[[Category:MQP-Prototypes]]
{{MQP:Navbar}}

==The Prototype==
This release demonstrates the structure of the Resource Model and the functionality of the mechanism that populates it. The release consists of one XML file with the resource definitions and one executable JAR containing the program with source. The release is available [https://sourceforge.wpi.edu/sf/frs/do/viewRelease/projects.java_security_analysis_tool/frs.resource_model_definition_protot.proof_of_concept_program?_message=1222385766451 here].

==A Simple Walkthrough==
Save the JAR and XML file in the same directory for ease of execution. To run the demonstration use the directory the JAR is in as the working directory and run the following command:
<pre>
java -jar ResourceModelProofOfConcept0-1.jar resourceDefinitionDraft1.xml
</pre>

This will cause the resource definitions to be loaded, then the resource model structure will be output to standard out.

==Some Explanation of Output==
The intent of this release is to show that the resource model exists and is functional, and we can show what information can be loaded into the model from an xml file (in this case, resourceDefinitionDraft1).

A sample of the output of a ''Resource'' is shown here:

<pre>
...
Socket Connections
Actions:
SocketAccept
ActionParameters:
hostname
portrange
RuleDefinitions:
SocketPermission([host:{hostname}:{portrange}] [action:accept] )
...
</pre>

This says that the "resource" in question is Socket Connections, and the current "action" is accepting. This action has two parameters - hostname and portrange. This action has a rule defined for it (so far the only security rules we have are for permissions, but the model would allow this to be extended). The permission rule shown here is for a SocketPermission, and it takes two parameters, called the host and the action. The "host" element results from applying the two action parameters in the format shown. The "action" element of the permission rule is directly related to the action in question - it is the string "accept".

The corresponding permission rule, containing the host and action parameters that the action parameters are applied to, looks like this:

<pre>
...
SocketPermission
Parameters:
1: host
2: action

The permission used for Socket connect, accept, listen, and
resolve actions. Parameters are host and action.

...
</pre>

==Limitations==
*This version requires a connection to the Internet in order to look up the XML schema.
*The JAR is enormous. In order to get it packaged quickly, we included way too much stuff.
*There are libraries within the JAR that should be stored separately.

MQP:Rule to Resource Mapping

2008-09-16T21:01:46Z

Jpolitz: /* Resources */

MQP:Rule to Resource Mapping

2008-09-16T20:57:53Z

Jpolitz: /* Resources */

MQP:Rule to Resource Mapping

2008-09-16T19:25:11Z

Jpolitz: /* Resource to Permission Data Model */

MQP:Rule to Resource Mapping

2008-09-16T19:24:05Z

Jpolitz: /* Resource to Permission Data Model */

MQP:A Thread Example

2008-09-15T20:45:11Z

Jpolitz:

{{MQP:Navbar}}

==Analyzing Calls to Thread.start()==

This section describes how Koved's method for handling Thread.run() invocations in security call graphs can apply to different subclasses of Thread.

Analyzing security information about permissions required when Thread.start() is called is a bit different from a normal method invocation. The start() method is being invoked on some Thread object, or an object that is a subclass of Thread, and this object may not have been created in the current security context. The run() method specified by the object (whether the run() method is actually overridden or through use of a Runnable passed to the Thread constructor) represents code that should be executed in the context of that created the Thread, not the context that calls Thread.start().

For this reason, it is not appropriate to traverse normally back through Thread.run() to the method that invoked Thread.start(). Instead, the correct behavior is to traverse back to the constructor of the type of Thread in question, which will in turn lead to each method that instantiated a Thread of that type.

In the following diagram, we model the behavior of a program that is creating two different types of Threads, a MyThread and a WorkerThread. The dotted lines represent implicit calls to Thread.run() through Thread.start(), which is not shown (this is the way that Soot models this type of call in its call graph, and is convenient for our purposes). The nodes that are red require the permission from MyThread.run(), the nodes that are blue require the permission from WorkerThread.run(). The purple node requires both types of permissions, since it instantiated both types of Thread. The red and blue edges represent the new edges that would be traversed in the call graph as a result of using this method. The black nodes require no additional permissions from the calls to the run() methods.

[[Image:ThreadExampleNoStart.png|frame|center|Thread Example]]

MQP:Static Analysis Strategies

2008-09-15T20:43:48Z

Jpolitz: /* Current Work */

[[Category:MQP-Design]]
{{MQP:Navbar}}

==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 [http://www.research.ibm.com/javasec/OOPSLA2002preprint.pdf 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 operation, 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.

==Special Cases==

# A full example handling of the Thread.start() case is available [[MQP:A Thread Example|here]]
# For calls to doPrivileged, the graph traversal simply terminates at nodes that have a edge from the doPrivileged method entering into them.
# Some applications have methods that anticipate SecurityExceptions being thrown, and so may not actually require the grant for the Permission object that is passed to a checkPermission call. This case is similar to the doPrivileged case, since the graph traversal does not need to continue past the method that caught the SecurityException, except in the case where there are transitive calls to checkPermission in the catch block, which need to be handled separately.

==Locating Arguments Passed to Permission Constructors==

Once the program point that calls SecurityManager.checkPermission is found, it is simple to extract the expression that is passed as the Permission argument to the method. From this program point, the list of statements in the body of the method is traversed backwards to find an instance of the constructor call to the relevant Permission type, or assignment statements to the variable passed to checkPermission. This analysis only considers the method that called checkPermission, which is a simplifying assumption. If the constructor is found, then the expressions passed to the constructor can be extracted, and a similar traversal can be performed on these expressions to find their initialization. The difference in this case is that these expressions (almost always String objects), are often declared as static fields, so the static initializers of the relevant methods are also inspected to find definitions of static fields. This analysis is sufficient for many simple cases, but misses many others, most commonly when the expressions passed to the Permission constructor come into the method as parameters and their runtime values are more difficult (or impossible) to determine.

Much of the simplicity of this traversal is due to the intermediate format Jimple from Soot, which simplifies compound expressions in Java statements. This creates a number of extra, temporary local variables, which makes the each relevant program point into either an assignment statement or a method invocation. At the moment, this analysis does not take into account branching in the control flow of the method, which could lead to finding multiple possible values for each argument. In this case, it would be necessary to report all possible values that could be found, leading to a more complicated result set.

==Current Work==

At the moment, we have completed the basic structure of the baseline analysis algorithm. Using the CallGraph created in the Soot analysis, we can find which methods call checkPermissions. Then we can traverse the call graph and accumulate the Permissions in the methods that can reach the permission-requiring methods. The result is a collection of Permissions needed by each method annotated by which method the Permission was originally checked in. This information has been integrated with the data structures for the analysis model to provide an organized way to represent the results in the eventual application.

Some issues that exist currently and may be worked out as the project progresses are:
# The call graph is large for several reasons, the most prominent of which is the difficulty of resolving virtual method calls. This leads to a overly conservative analysis.
# The analysis to find the fields of Permission objects is limited, which makes the results less valuable in some cases.
# The fields of Permission objects need to be further analyzed in many cases to resolve into grants in a policy file, for example parsing the String objects in a SocketPermission to find the actual socket or range of sockets in question.

==More?==

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

MQP:Static Analysis Strategies

2008-09-15T20:39:20Z

Jpolitz: /* Location Arguments Passed to Permission Constructors */

[[Category:MQP-Design]]
{{MQP:Navbar}}

==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 [http://www.research.ibm.com/javasec/OOPSLA2002preprint.pdf 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 operation, 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.

==Special Cases==

# A full example handling of the Thread.start() case is available [[MQP:A Thread Example|here]]
# For calls to doPrivileged, the graph traversal simply terminates at nodes that have a edge from the doPrivileged method entering into them.
# Some applications have methods that anticipate SecurityExceptions being thrown, and so may not actually require the grant for the Permission object that is passed to a checkPermission call. This case is similar to the doPrivileged case, since the graph traversal does not need to continue past the method that caught the SecurityException, except in the case where there are transitive calls to checkPermission in the catch block, which need to be handled separately.

==Locating Arguments Passed to Permission Constructors==

Once the program point that calls SecurityManager.checkPermission is found, it is simple to extract the expression that is passed as the Permission argument to the method. From this program point, the list of statements in the body of the method is traversed backwards to find an instance of the constructor call to the relevant Permission type, or assignment statements to the variable passed to checkPermission. This analysis only considers the method that called checkPermission, which is a simplifying assumption. If the constructor is found, then the expressions passed to the constructor can be extracted, and a similar traversal can be performed on these expressions to find their initialization. The difference in this case is that these expressions (almost always String objects), are often declared as static fields, so the static initializers of the relevant methods are also inspected to find definitions of static fields. This analysis is sufficient for many simple cases, but misses many others, most commonly when the expressions passed to the Permission constructor come into the method as parameters and their runtime values are more difficult (or impossible) to determine.

Much of the simplicity of this traversal is due to the intermediate format Jimple from Soot, which simplifies compound expressions in Java statements. This creates a number of extra, temporary local variables, which makes the each relevant program point into either an assignment statement or a method invocation. At the moment, this analysis does not take into account branching in the control flow of the method, which could lead to finding multiple possible values for each argument. In this case, it would be necessary to report all possible values that could be found, leading to a more complicated result set.

==Current Work==

At the moment, we have completed the basic structure of the baseline analysis algorithm. Using the CallGraph created in the Soot analysis, we can find which methods call checkPermissions. Then we can traverse the call graph and accumulate the Permissions in the methods that can reach the permission-requiring methods. The result is a collection of Permissions needed by each method annotated by which method the Permission was originally checked in. This information has been integrated with the data structures for the analysis model to provide an organized way to represent the results in the eventual application.

Next, we will try to find ways to identify the arguments passed to the Permission objects themselves, to better describe the Permissions needed at the top level. After that we will need to take into consideration the special cases mentioned in the baseline analysis, including doPrivileged, Threads, and Exceptions.

==More?==

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

MQP:Static Analysis Strategies

2008-09-15T20:34:00Z

Jpolitz:

[[Category:MQP-Design]]
{{MQP:Navbar}}

==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 [http://www.research.ibm.com/javasec/OOPSLA2002preprint.pdf 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 operation, 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.

==Special Cases==

# A full example handling of the Thread.start() case is available [[MQP:A Thread Example|here]]
# For calls to doPrivileged, the graph traversal simply terminates at nodes that have a edge from the doPrivileged method entering into them.
# Some applications have methods that anticipate SecurityExceptions being thrown, and so may not actually require the grant for the Permission object that is passed to a checkPermission call. This case is similar to the doPrivileged case, since the graph traversal does not need to continue past the method that caught the SecurityException, except in the case where there are transitive calls to checkPermission in the catch block, which need to be handled separately.

==Location Arguments Passed to Permission Constructors==

Once the program point that calls SecurityManager.checkPermission is found, it is simple to extract the expression that is passed as the Permission argument to the method. From this program point, the list of statements in the body of the method is traversed backwards to find an instance of this expression having <init> called on it, or being assigned to another variable or field. This analysis only considers the method that called checkPermission, which is a simplifying assumption. If the constructor is found, then the expressions passed to the constructor can be extracted, and a similar traversal can be performed on these expressions to find their initialization. The difference in this case is that these expressions (almost always String objects), are often declared as static fields, so the static initializers of the relevant methods are also inspected to find definitions of static fields. This analysis is sufficient for many simple cases, but misses many others, most commonly when the expressions passed to the Permission constructor come into the method as parameters and their runtime values are more difficult (or impossible) to determine.

==Current Work==

At the moment, we have completed the basic structure of the baseline analysis algorithm. Using the CallGraph created in the Soot analysis, we can find which methods call checkPermissions. Then we can traverse the call graph and accumulate the Permissions in the methods that can reach the permission-requiring methods. The result is a collection of Permissions needed by each method annotated by which method the Permission was originally checked in. This information has been integrated with the data structures for the analysis model to provide an organized way to represent the results in the eventual application.

Next, we will try to find ways to identify the arguments passed to the Permission objects themselves, to better describe the Permissions needed at the top level. After that we will need to take into consideration the special cases mentioned in the baseline analysis, including doPrivileged, Threads, and Exceptions.

==More?==

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

MQP:Project Overview

2008-09-15T20:14:42Z

Jpolitz:

[[Category:MQP]]
{{MQP:Navbar}}
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 [[MQP:Permission to Resource Mapping|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 [[MQP:Static_Analysis_Strategies|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>
[1] T13: Finish initial definition of Resource model
[1] 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] 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
[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
[ ] 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>

MQP:Project Overview

2008-09-15T19:59:46Z

Jpolitz:

[[Category:MQP]]
{{MQP:Navbar}}
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.
===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 [[MQP:Static_Analysis_Strategies|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>
[1] T13: Finish initial definition of Resource model
[1] 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] 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
[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
[ ] 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>

MQP:Project Overview

2008-09-15T18:46:17Z

Jpolitz: /* Project Schedule and Goals */

[[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.

==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 [[MQP:Static_Analysis_Strategies|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>
[1] T13: Finish initial definition of Resource model
[1] 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] 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
[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
[ ] 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>

MQP:Main

2008-09-12T19:12:29Z

Jpolitz:

This project will attempt to devise a method for determining the appropriate permission set for an application written in Java and create a developer tool implementing the method.

See the [[MQP:Project Overview|Project Overview]] for more.
{{MQP:Navbar}}

==Research Topics==
*[[MQP:Static Analysis Tools|Static Analysis Tools]]
**[[MQP:More on Soot|More on Soot]]
*[[MQP:Java Security|Java Security]]

==Design Topics==
*[[MQP:Static Analysis Strategies|Static Analysis Strategies]]
**[[MQP: A Thread Example|A Thread Example]]
*[[MQP:Security Analysis Data Structure|Security Analysis Data Model]]
*[[MQP:Introduction to Netbeans Integration|Introduction to Netbeans Integration]]
*[[MQP:Permission to Resource Mapping|Permission to Resource Mapping]]

==Proofs of Concept==
*[[MQP:Static Analysis Tool 0.1|Static Analysis Tool 0.1]]

==The Team==
*[[Special:Emailuser/J|James Cialdea]] - WPI Class of 2009
**Computer Science Major
**Computer Engineering Minor
*[[Special:Emailuser/jpolitz|Joe Politz]] - WPI Class of 2009
**Computer Science Major
**Mathematics Minor
*A few WPI Advisors
*A few Sun Microsystems Project Sponsors

[[Category:MQP]]

MQP:Main

2008-09-12T19:09:31Z

Jpolitz:

This project will attempt to devise a method for determining the appropriate permission set for an application written in Java and create a developer tool implementing the method.

See the [[MQP:Project Overview|Project Overview]] for more.
{{MQP:Navbar}}

==Research Topics==
*[[MQP:Static Analysis Tools|Static Analysis Tools]]
**[[MQP:More on Soot|More on Soot]]
*[[MQP:Java Security|Java Security]]

==Design Topics==
*[[MQP:Static Analysis Strategies|Static Analysis Strategies]]
**[[MQP: A Thread Example|A Thread Example]]
*[[MQP:Security Analysis Data Structure|Security Analysis Data Model]]
*[[MQP:Introduction to Netbeans Integration|Introduction to Netbeans Integration]]
*[[MQP:Permission to Resource Mapping|Permission to Resource Mapping]]

==Proofs of Concept==
*[[MQP:Static Analysis Tool 0.1|Static Analysis Tool 0.1]]

==The Team==
*[[Special:Emailuser/J|James Cialdea]] - WPI Class of 2009
**Computer Science Major
**Computer Engineering Minor
*Joe Politz - WPI Class of 2009
**Computer Science Major
**Mathematics Minor
*A few WPI Advisors
*A few Sun Microsystems Project Sponsors

[[Category:MQP]]

Category:MQP-Prototypes

2008-09-12T19:08:42Z

Jpolitz: New page: Category:MQP

[[Category:MQP]]

MQP:Static Analysis Tool 0.1

2008-09-12T19:08:03Z

Jpolitz:

[[Category:MQP-Prototypes]]

{{MQP:Navbar}}

==The Prototype==

The initial prototype of the static analysis tool is available [https://sourceforge.wpi.edu/sf/frs/do/viewRelease/projects.java_security_analysis_tool/frs.proofofconcept0_1.proofofconcept0_1?_message=1221246979560 here]. The tool at the moment has a simple command line interface, and only has the static analysis tool using Soot available. The current version approximates the security requirements of a program ''very'' conservatively.

==A Simple Walkthrough==

To run the tool, invoke the following command (this ensures the JVM will have enough memory to handle the large call graph that will be created).

<pre>
java -Xmx600m -jar proofOfConcept0-1.jar
</pre>

When this runs, a shell prompt should appear like this:

<pre>
SecurityAnalyzer:>
</pre>

The "run" command runs analyses on tools. Currently the only tool available is the "SootAnalysisTool," which has tool number 1. The run command takes in a tool number, a directory in which to the source to be analyzed is located, and the fully qualified java classname of the main class of the application. In the future, it will be easier to specify different entry points other than a main class. To run the included test, invoke the run command as follows:

<pre>
SecurityAnalyzer:> run 1 Tests/ test.Test
</pre>

This will take a while to run (a very large call graph is being generated). The results of the analysis should appear in the directory in which the jar is located in a file called 'results.txt'. Specify other code sources to analyze by changing the directory to be analyzed, which must be the root of the package structure of the java code to be analyzed.

==Limitations==

Viewing the result file should make it apparent how conservative the tool is right now. Further work on narrowing down the runtime types of virtual method calls could help this somewhat, along with other improvements to the call graph construction. However, this prototype represents a proof of concept of this basic part of the analysis.

MQP:Static Analysis Tool 0.1

2008-09-12T18:56:06Z

Jpolitz:

[[Category:MQP-Prototypes]]

{{MQP:Navbar}}

==The Prototype==

The initial prototype of the static analysis tool is available in this release. The tool at the moment has a simple command line interface, and only has the static analysis tool using Soot available. The current version approximates the security requirements of a program ''very'' conservatively.

==A Simple Walkthrough==

To run the tool, invoke the following command (this ensures the JVM will have enough memory to handle the large call graph that will be created).

<pre>
java -Xmx600m -jar proofOfConcept0-1.jar
</pre>

When this runs, a shell prompt should appear like this:

<pre>
SecurityAnalyzer:>
</pre>

The "run" command runs analyses on tools. Currently the only tool available is the "SootAnalysisTool," which has tool number 1. The run command takes in a tool number, a directory in which to the source to be analyzed is located, and the fully qualified java classname of the main class of the application. In the future, it will be easier to specify different entry points other than a main class. To run the included test, invoke the run command as follows:

<pre>
SecurityAnalyzer:> run 1 Tests/ test.Test
</pre>

This will take a while to run (a very large call graph is being generated). The results of the analysis should appear in the directory in which the jar is located in a file called 'results.txt'. Specify other code sources to analyze by changing the directory to be analyzed, which must be the root of the package structure of the java code to be analyzed.

==Limitations==

Viewing the result file should make it apparent how conservative the tool is right now. Further work on narrowing down the runtime types of virtual method calls could help this somewhat, along with other improvements to the call graph construction. However, this prototype represents a proof of concept of this basic part of the analysis.

MQP:Static Analysis Tool 0.1

2008-09-12T18:42:31Z

Jpolitz: /* A Simple Walkthrough */

[[Category:MQP-Prototypes]]

{{MQP:Navbar}}

==The Prototype==

The initial prototype of the static analysis tool is available in this release. The tool at the moment has a simple command line interface, and only has the static analysis tool using Soot available. The current version approximates the security requirements of a program ''very'' conservatively.

==A Simple Walkthrough==

To run the tool, invoke the following command (this ensures the JVM will have enough memory to handle the large call graph that will be created).

<pre>
java -Xmx600m -jar proofOfConcept0-1.jar
</pre>

When this runs, a shell prompt should appear like this:

<pre>
SecurityAnalyzer:>
</pre>

The "run" command runs analyses on tools. Currently the only tool available is the "SootAnalysisTool," which has tool number 1. The run command takes in a tool number, a directory in which to the source to be analyzed is located, and the fully qualified java classname of the main class of the application. In the future, it will be easier to specify different entry points other than a main class. To run the included test, invoke the run command as follows:

<pre>
SecurityAnalyzer:> run 1 test/ test.Test
</pre>

This will take a while to run (a very large call graph is being generated). The results of the analysis should appear in the directory in which the jar is located in a file called 'results.txt'. Specify other code sources to analyze by changing the directory to be analyzed, which must be the root of the package structure of the java code to be analyzed.

==Limitations==

Viewing the result file should make it apparent how conservative the tool is right now. Further work on narrowing down the runtime types of virtual method calls could help this somewhat, along with other improvements to the call graph construction. However, this prototype represents a proof of concept of this basic part of the analysis.

MQP:Static Analysis Tool 0.1

2008-09-12T18:42:09Z

Jpolitz: /* A Simple Walkthrough */

[[Category:MQP-Prototypes]]

{{MQP:Navbar}}

==The Prototype==

The initial prototype of the static analysis tool is available in this release. The tool at the moment has a simple command line interface, and only has the static analysis tool using Soot available. The current version approximates the security requirements of a program ''very'' conservatively.

==A Simple Walkthrough==

To run the tool, invoke the following command (this ensures the JVM will have enough memory to handle such a large call graph).

<pre>
java -Xmx600m -jar proofOfConcept0-1.jar
</pre>

When this runs, a shell prompt should appear like this:

<pre>
SecurityAnalyzer:>
</pre>

The "run" command runs analyses on tools. Currently the only tool available is the "SootAnalysisTool," which has tool number 1. The run command takes in a tool number, a directory in which to the source to be analyzed is located, and the fully qualified java classname of the main class of the application. In the future, it will be easier to specify different entry points other than a main class. To run the included test, invoke the run command as follows:

<pre>
SecurityAnalyzer:> run 1 test/ test.Test
</pre>

This will take a while to run (a very large call graph is being generated). The results of the analysis should appear in the directory in which the jar is located in a file called 'results.txt'. Specify other code sources to analyze by changing the directory to be analyzed, which must be the root of the package structure of the java code to be analyzed.

==Limitations==

Viewing the result file should make it apparent how conservative the tool is right now. Further work on narrowing down the runtime types of virtual method calls could help this somewhat, along with other improvements to the call graph construction. However, this prototype represents a proof of concept of this basic part of the analysis.

MQP:Static Analysis Tool 0.1

2008-09-12T18:41:07Z

Jpolitz: New page: Category:MQP-Prototypes {{MQP:Navbar}} ==The Prototype== The initial prototype of the static analysis tool is available in this release. The tool at the moment has a simple command...

[[Category:MQP-Prototypes]]

{{MQP:Navbar}}

==The Prototype==

The initial prototype of the static analysis tool is available in this release. The tool at the moment has a simple command line interface, and only has the static analysis tool using Soot available. The current version approximates the security requirements of a program ''very'' conservatively.

==A Simple Walkthrough==

To run the tool, invoke the

<pre>
java -Xmx600m -jar proofOfConcept0-1.jar
</pre>

When the tool is run, a shell prompt should appear like this:

<pre>
SecurityAnalyzer:>
</pre>

The "run" command runs analyses on tools. Currently the only tool available is the "SootAnalysisTool," which has tool number 1. The run command takes in a tool number, a directory in which to the source to be analyzed is located, and the fully qualified java classname of the main class of the application. In the future, it will be easier to specify different entry points other than a main class. To run the included test, invoke the run command as follows:

<pre>
SecurityAnalyzer:> run 1 test/ test.Test
</pre>

This will take a while to run (a very large call graph is being generated). The results of the analysis should appear in the directory in which the jar is located in a file called 'results.txt'. Specify other code sources to analyze by changing the directory to be analyzed, which must be the root of the package structure of the java code to be analyzed.

==Limitations==

Viewing the result file should make it apparent how conservative the tool is right now. Further work on narrowing down the runtime types of virtual method calls could help this somewhat, along with other improvements to the call graph construction. However, this prototype represents a proof of concept of this basic part of the analysis.

MQP:Main

2008-09-12T18:12:25Z

Jpolitz:

This project will attempt to devise a method for determining the appropriate permission set for an application written in Java and create a developer tool implementing the method.

See the [[MQP:Project Overview|Project Overview]] for more.
{{MQP:Navbar}}

==Research Topics==
*[[MQP:Static Analysis Tools|Static Analysis Tools]]
**[[MQP:More on Soot|More on Soot]]
*[[MQP:Java Security|Java Security]]

==Design Topics==
*[[MQP:Static Analysis Strategies|Static Analysis Strategies]]
**[[MQP: A Thread Example|A Thread Example]]
*[[MQP:Security Analysis Data Structure|Security Analysis Data Model]]
*[[MQP:Introduction to Netbeans Integration|Introduction to Netbeans Integration]]
*[[MQP:Permission to Resource Mapping|Permission to Resource Mapping]]

==File Releases==
*[[MQP:Static Analysis Tool 0.1|Static Analysis Tool 0.1]]

==The Team==
*[[Special:Emailuser/J|James Cialdea]] - WPI Class of 2009
**Computer Science Major
**Computer Engineering Minor
*Joe Politz - WPI Class of 2009
**Computer Science Major
**Mathematics Minor
*A few WPI Advisors
*A few Sun Microsystems Project Sponsors

[[Category:MQP]]

MQP:A Thread Example

2008-09-05T15:00:02Z

Jpolitz: New page: ==Analyzing Calls to Thread.start()== This section describes how Koved's method for handling Thread.run() invocations in security call graphs can apply to different subclasses of Thread. ...

==Analyzing Calls to Thread.start()==

This section describes how Koved's method for handling Thread.run() invocations in security call graphs can apply to different subclasses of Thread.

Analyzing security information about permissions required when Thread.start() is called is a bit different from a normal method invocation. The start() method is being invoked on some Thread object, or an object that is a subclass of Thread, and this object may not have been created in the current security context. The run() method specified by the object (whether the run() method is actually overridden or through use of a Runnable passed to the Thread constructor) represents code that should be executed in the context of that created the Thread, not the context that calls Thread.start().

For this reason, it is not appropriate to traverse normally back through Thread.run() to the method that invoked Thread.start(). Instead, the correct behavior is to traverse back to the constructor of the type of Thread in question, which will in turn lead to each method that instantiated a Thread of that type.

In the following diagram, we model the behavior of a program that is creating two different types of Threads, a MyThread and a WorkerThread. The dotted lines represent implicit calls to Thread.run() through Thread.start(), which is not shown (this is the way that Soot models this type of call in its call graph, and is convenient for our purposes). The nodes that are red require the permission from MyThread.run(), the nodes that are blue require the permission from WorkerThread.run(). The purple node requires both types of permissions, since it instantiated both types of Thread. The red and blue edges represent the new edges that would be traversed in the call graph as a result of using this method. The black nodes require no additional permissions from the calls to the run() methods.

[[Image:ThreadExampleNoStart.png|frame|center|Thread Example]]

File:ThreadExampleNoStart.png

2008-09-05T14:44:07Z

Jpolitz: image for thread example

image for thread example

MQP:Main

2008-09-05T14:42:27Z

Jpolitz:

This project will attempt to devise a method for determining the appropriate permission set for an application written in Java and create a developer tool implementing the method.
{{MQP:Navbar}}

==Research Topics==
*[[MQP:Static Analysis Tools|Static Analysis Tools]]
**[[MQP:More on Soot|More on Soot]]
*[[MQP:Java Security|Java Security]]

==Design Topics==
*[[MQP:Static Analysis Strategies|Static Analysis Strategies]]
**[[MQP: A Thread Example|A Thread Example]]
*[[MQP:Security Analysis Data Structure|Security Analysis Data Structure]]
*[[MQP:Introduction to Netbeans Integration|Introduction to Netbeans Integration]]

==The Team==
*[[Special:Emailuser/J|James Cialdea]] - WPI Class of 2009
**Computer Science Major
**Computer Engineering Minor
*Joe Politz - WPI Class of 2009
**Computer Science Major
**Mathematics Minor
*A few WPI Advisors
*A few Sun Microsystems Project Sponsors

[[Category:MQP]]

MQP:Introduction to Netbeans Integration

2008-09-05T14:39:43Z

Jpolitz: New page: Category:MQP-Research {{MQP:Navbar}} ==Why Netbeans?== There are a few reasons why taking the security analysis tool and integrating it with Netbeans would be effective. Netbeans al...

[[Category:MQP-Research]]
{{MQP:Navbar}}

==Why Netbeans?==

There are a few reasons why taking the security analysis tool and integrating it with Netbeans would be effective. Netbeans already supports plugins for developing Glassfish applications, so development help could be available in the IDE for writing secure applications for Glassfish specifically. Netbeans uses a version of the javac representation of the parse tree and source model, which could be leveraged in static analysis. This representation can also be easily used to display information back to developers that could come from the security tool.

====Existing Features====

A few existing features of Netbeans seem they could be relevant for this project. The idea of doing a reverse lookup (like finding usages of a variable or method) is similar to the way our tool traverses call graphs (by looking for methods that call a given method). Netbeans also does several steps in the parsing of source code that could be useful in static analysis, in addition to compiling source files to bytecode. The classpath of library classes that are in jar files are also easily available through Netbeans' project structure.

====Netbeans Source Model====

Netbeans uses the structural model of Java bytecode found in the package javax.lang.model. This includes information about classes, their method signatures, and fields of the methods, and is specified by JSR 269. There is also a more fine-grain model of source that Netbeans uses in the package com.sun.source.tree. This package models more detailed information about the bodies of methods and the statements enclosed within. Were we to use this source model entirely (instead of another option like Soot's), this would be the model we would start with to represent a call graph.

While Netbeans is running, a plugin can request access to these source models at different levels of completeness in the parsing and compiling process. If a tool or plugin is running in the background of Netbeans, it should only request access to the level of information that it needs to perform its computation. If a user updates code while our tool is running, we would almost always need full information to update our analysis, since any method calls that are added or removed could affect the call graph.

====Communicating Results====

An important reason for doing IDE integration in the first place is to allow the tool to communicate with developers in a simple way and without having to switch environments. Netbeans would allow the tool to markup code or show information to developers in the editor window or with dialog boxes (say during a simulation mode). Things like the syntax highlighting that Netbeans already does, as well as graphical output of code coverage or other profiling tools, are good examples of ways that information can be quickly shown to a developer without leaving the IDE or being overly intrusive.

MQP:Main

2008-09-05T14:39:04Z

Jpolitz:

This project will attempt to devise a method for determining the appropriate permission set for an application written in Java and create a developer tool implementing the method.
{{MQP:Navbar}}

==Research Topics==
*[[MQP:Static Analysis Tools|Static Analysis Tools]]
**[[MQP:More on Soot|More on Soot]]
*[[MQP:Java Security|Java Security]]

==Design Topics==
*[[MQP:Static Analysis Strategies|Static Analysis Strategies]]
*[[MQP:Security Analysis Data Structure|Security Analysis Data Structure]]
*[[MQP:Introduction to Netbeans Integration|Introduction to Netbeans Integration]]

==The Team==
*[[Special:Emailuser/J|James Cialdea]] - WPI Class of 2009
**Computer Science Major
**Computer Engineering Minor
*Joe Politz - WPI Class of 2009
**Computer Science Major
**Mathematics Minor
*A few WPI Advisors
*A few Sun Microsystems Project Sponsors

[[Category:MQP]]

MQP:Netbeans API Overview

2008-09-05T14:37:55Z

MQP:Main

2008-09-04T19:08:32Z

Jpolitz:

This project will attempt to devise a method for determining the appropriate permission set for an application written in Java and create a developer tool implementing the method.
{{MQP:Navbar}}

==Research Topics==
*[[MQP:Static Analysis Tools|Static Analysis Tools]]
**[[MQP:More on Soot|More on Soot]]
*[[MQP:Java Security|Java Security]]

==Design Topics==
*[[MQP:Static Analysis Strategies|Static Analysis Strategies]]
*[[MQP:Security Analysis Data Structure|Security Analysis Data Structure]]
*[[MQP:Netbeans API Overview|Netbeans API Overview]]

==The Team==
*[[Special:Emailuser/J|James Cialdea]] - WPI Class of 2009
**Computer Science Major
**Computer Engineering Minor
*Joe Politz - WPI Class of 2009
**Computer Science Major
**Mathematics Minor
*A few WPI Advisors
*A few Sun Microsystems Project Sponsors

[[Category:MQP]]

MQP:Static Analysis Strategies

2008-09-02T20:17:11Z

Jpolitz:

MQP:Static Analysis Strategies

2008-08-27T20:12:33Z

Jpolitz: /* Deep Analysis */

MQP:Static Analysis Strategies

2008-08-26T20:18:39Z

Jpolitz: New page: {{#categorytree:MQP|hideroot|mode=pages}} ==Overview== This page summarizes some of our discussions on strategies for performing static analysis to infer permissions. ==Goals== The bes...

{{#categorytree:MQP|hideroot|mode=pages}}

==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 [http://www.research.ibm.com/javasec/OOPSLA2002preprint.pdf 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.

MQP:Main

2008-08-26T19:57:50Z

Jpolitz: /* Research Topics */

This is where the MQP stuff goes.
{{MQP:Navbar}}

==Research Topics==
*[[MQP:Static Analysis Tools|Static Analysis Tools]]
**[[MQP:More on Soot|More on Soot]]
*[[MQP:Java Security|Java Security]]
*[[MQP:Static Analysis Strategies|Static Analysis Strategies]]

[[Category:MQP]]

MQP:More on Soot

2008-08-26T19:55:39Z

Jpolitz: /* More to Come */

{{#categorytree:MQP|hideroot|mode=pages}}

==Overview==

Soot is a useful tool for static analysis mentioned in the static analysis tools section. Some of its features are covered in more detail here.

==What Soot Does==

Soot takes Java source code, bytecode, or classfiles as input and converts them into different representations or models of the code. These representations simplify the process of performing many tasks, including several types of static analysis. For this project in particular, we will be especially interested in Soot's ability to make call graphs and operate on them. Some of the other types of static analysis that Soot facilitates may also factor in to this project.

====Intermediate Representations====

There are four different models that Soot uses for representing Java Code, each with different uses. We're still learning what each of these does exactly (working from http://www.brics.dk/SootGuide/).

#Baf - This representation allows for inspection of Java bytecode as "stack code." Still learning about this and what it means.
#Jimple - This representation is the most commonly used intermediate model. It breaks complicated statements down into more basic ones (for example, i = x + y + z could become i0 = x + y; i = i0 + z), to simplify statement by statement analysis.
#Shimple - This model is similar to Jimple, but has the ability to remember different values for variables dependent on branching in the program (if two branches set a variable x in different ways, then at the end Shimple may have two variables, x0 and x1, that represent two possible values of x). This can lead to simplifications if it is found that the branches yield identical results for some identifiers.
#Grimp - This model looks the most like "normal" Java code, and has the least simplifications of the four models.

====Analyses and Data Models====

From these intermediate representations, Soot creates several different abstract models of the code, and can perform a few types of analyses on these models.

#Call Graph - Creating a call graph is necessary for any type of interprocedural analysis (one that handles control flow that changes via method invocations). The call graph in Soot is based on a class hierarchy model, so the Method objects represented by Soot have information about what class they belong to and what fields they have access to. Soot also provides different methods for traversing the call graph and finding methods reachable from others.
#Data Flow Analyses - Soot also has tools that allow the user to specify specific data flow analyses to perform on the model. The user can specify if it is a forward or backward analysis, a may or must analysis, and several other options.
#Points-to Analysis - Soot has specific tools for performing a points-to analysis, which can be used to determine what values pointers (Java references) could be referring to at a given program point. This could be useful in this project in determining the arguments to Permission objects to refine the knowledge of which permissions are needed.

====More to Come====

There will likely be more information available on Soot the more it and its uses are investigated. UPDATE: Got Soot up and running on the command line, and can build and run it from eclipse. Next is to work on our own tools to utilize the API and classes that are already there.

====References====
Soot Survival Guide - http://www.brics.dk/SootGuide/

MQP:Static Analysis Tools

2008-08-26T14:58:10Z

Jpolitz: /* References */

{{#categorytree:MQP|hideroot|mode=pages}}

==What We're Looking For==

For the kind of static analysis we're doing, some sort of a call graph is needed to model the flow of the program and where calls to checkPermissions are going to be found. To that end, we investigated some static analysis tools that provide models of Java code and ways to inspect it.

More tools may be added as the project continues.
{{Incomplete}}

==Some Tools==

====Java Compiler API====

The Java Compiler API provides access to the functionality of the Java Compiler, most notably the ability to create an Abstract Syntax Tree of some set of Java code. This is a straightforward tool, but does not seem to have any simple provision for creating a customizable call graph, which would be ideal for our application.

====NetBeans API for Call Hierarchy====

NetBeans has an API for accessing the code model used internally in the program. NetBeans itself does have a sort of call graph functionality in the "Call Hierarchy" tool. This could prove useful, but at this point in time we would rather focus on tools that aren't dependent on an IDE, and let us create a standalone application.

====Soot====

Soot is a "Java optimization framework," and provides a large number of tools that can (and have been) used to perform static analysis of Java programs. Soot has a number of features that we are looking for:
# Analyzes Java source, bytecode, and class files
# Creates a call graph based on class hierarchy
# Is free and open source (LGPL License)
# Can be used outside any IDE
# Is tested by use in a number of research applications
# Has a other static analysis applications (data flow analysis, points-to analysis) which could be applicable to security

Soot is a likely candidate for use in the security static analysis. [[MQP:More on Soot|More on Soot]]

====Other Tools====

Other tools that were looked at and may be considered for reference are TACLE (Type Analysis and Call Graph Construction for Eclipse), and a program verification tool called Bandera that used Soot and has an implementation of their own CallGraph class. Other tools may be considered or added as the project continues.

==References==
#Soot - http://www.sable.mcgill.ca/soot/
#NetBeans API for Call Hierarchy (in Java Source package) - http://bits.netbeans.org/dev/javadoc/index.html
#javac API - http://java.sun.com/javase/6/docs/technotes/guides/javac/index.html
#Larry Koved's excellent paper on access rights analysis for java - [http://www.research.ibm.com/javasec/OOPSLA2002preprint.pdf Access Rights Analysis for Java]

[[Category:MQP]]

MQP:Static Analysis Tools

2008-08-26T14:55:53Z

Jpolitz: /* Soot */

{{#categorytree:MQP|hideroot|mode=pages}}

==What We're Looking For==

For the kind of static analysis we're doing, some sort of a call graph is needed to model the flow of the program and where calls to checkPermissions are going to be found. To that end, we investigated some static analysis tools that provide models of Java code and ways to inspect it.

More tools may be added as the project continues.
{{Incomplete}}

==Some Tools==

====Java Compiler API====

The Java Compiler API provides access to the functionality of the Java Compiler, most notably the ability to create an Abstract Syntax Tree of some set of Java code. This is a straightforward tool, but does not seem to have any simple provision for creating a customizable call graph, which would be ideal for our application.

====NetBeans API for Call Hierarchy====

NetBeans has an API for accessing the code model used internally in the program. NetBeans itself does have a sort of call graph functionality in the "Call Hierarchy" tool. This could prove useful, but at this point in time we would rather focus on tools that aren't dependent on an IDE, and let us create a standalone application.

====Soot====

Soot is a "Java optimization framework," and provides a large number of tools that can (and have been) used to perform static analysis of Java programs. Soot has a number of features that we are looking for:
# Analyzes Java source, bytecode, and class files
# Creates a call graph based on class hierarchy
# Is free and open source (LGPL License)
# Can be used outside any IDE
# Is tested by use in a number of research applications
# Has a other static analysis applications (data flow analysis, points-to analysis) which could be applicable to security

Soot is a likely candidate for use in the security static analysis. [[MQP:More on Soot|More on Soot]]

====Other Tools====

Other tools that were looked at and may be considered for reference are TACLE (Type Analysis and Call Graph Construction for Eclipse), and a program verification tool called Bandera that used Soot and has an implementation of their own CallGraph class. Other tools may be considered or added as the project continues.

==References==
#Soot - http://www.sable.mcgill.ca/soot/
#NetBeans API for Call Hierarchy (in Java Source package) - http://bits.netbeans.org/dev/javadoc/index.html
#javac API - http://java.sun.com/javase/6/docs/technotes/guides/javac/index.html
#Larry Koved's excellent paper on access rights analysis for java - [http://portal.acm.org/ft_gateway.cfm?id=582452&type=pdf&coll=GUIDE&dl=GUIDE&CFID=634220&CFTOKEN=95929885 Access Rights Analysis for Java]

[[Category:MQP]]

MQP:Static Analysis Tools

2008-08-26T14:55:29Z

Jpolitz: /* Soot */

{{#categorytree:MQP|hideroot|mode=pages}}

==What We're Looking For==

For the kind of static analysis we're doing, some sort of a call graph is needed to model the flow of the program and where calls to checkPermissions are going to be found. To that end, we investigated some static analysis tools that provide models of Java code and ways to inspect it.

More tools may be added as the project continues.
{{Incomplete}}

==Some Tools==

====Java Compiler API====

The Java Compiler API provides access to the functionality of the Java Compiler, most notably the ability to create an Abstract Syntax Tree of some set of Java code. This is a straightforward tool, but does not seem to have any simple provision for creating a customizable call graph, which would be ideal for our application.

====NetBeans API for Call Hierarchy====

NetBeans has an API for accessing the code model used internally in the program. NetBeans itself does have a sort of call graph functionality in the "Call Hierarchy" tool. This could prove useful, but at this point in time we would rather focus on tools that aren't dependent on an IDE, and let us create a standalone application.

====Soot====

Soot is a "Java optimization framework," and provides a large number of tools that can (and have been) used to perform static analysis of Java programs. Soot has a number of features that we are looking for:
# Analyzes Java source, bytecode, and class files
# Creates a call graph based on class hierarchy
# Is free and open source (LGPL License)
# Can be used outside any IDE
# Is tested by use in a number of research applications
# Has a other static analysis applications (data flow analysis, points-to analysis) which could be applicable to security

Soot is a likely candidate for use in the security static analysis. [MQP:More on Soot|More on Soot]

====Other Tools====

Other tools that were looked at and may be considered for reference are TACLE (Type Analysis and Call Graph Construction for Eclipse), and a program verification tool called Bandera that used Soot and has an implementation of their own CallGraph class. Other tools may be considered or added as the project continues.

==References==
#Soot - http://www.sable.mcgill.ca/soot/
#NetBeans API for Call Hierarchy (in Java Source package) - http://bits.netbeans.org/dev/javadoc/index.html
#javac API - http://java.sun.com/javase/6/docs/technotes/guides/javac/index.html
#Larry Koved's excellent paper on access rights analysis for java - [http://portal.acm.org/ft_gateway.cfm?id=582452&type=pdf&coll=GUIDE&dl=GUIDE&CFID=634220&CFTOKEN=95929885 Access Rights Analysis for Java]

[[Category:MQP]]

MQP:Static Analysis Tools

2008-08-26T14:54:32Z

Jpolitz:

{{#categorytree:MQP|hideroot|mode=pages}}

==What We're Looking For==

For the kind of static analysis we're doing, some sort of a call graph is needed to model the flow of the program and where calls to checkPermissions are going to be found. To that end, we investigated some static analysis tools that provide models of Java code and ways to inspect it.

More tools may be added as the project continues.
{{Incomplete}}

==Some Tools==

====Java Compiler API====

The Java Compiler API provides access to the functionality of the Java Compiler, most notably the ability to create an Abstract Syntax Tree of some set of Java code. This is a straightforward tool, but does not seem to have any simple provision for creating a customizable call graph, which would be ideal for our application.

====NetBeans API for Call Hierarchy====

NetBeans has an API for accessing the code model used internally in the program. NetBeans itself does have a sort of call graph functionality in the "Call Hierarchy" tool. This could prove useful, but at this point in time we would rather focus on tools that aren't dependent on an IDE, and let us create a standalone application.

====Soot====

Soot is a "Java optimization framework," and provides a large number of tools that can (and have been) used to perform static analysis of Java programs. Soot has a number of features that we are looking for:
# Analyzes Java source, bytecode, and class files
# Creates a call graph based on class hierarchy
# Is free and open source (LGPL License)
# Can be used outside any IDE
# Is tested by use in a number of research applications
# Has a other static analysis applications (data flow analysis, points-to analysis) which could be applicable to security

Soot is a likely candidate for use in the security static analysis.

====Other Tools====

Other tools that were looked at and may be considered for reference are TACLE (Type Analysis and Call Graph Construction for Eclipse), and a program verification tool called Bandera that used Soot and has an implementation of their own CallGraph class. Other tools may be considered or added as the project continues.

==References==
#Soot - http://www.sable.mcgill.ca/soot/
#NetBeans API for Call Hierarchy (in Java Source package) - http://bits.netbeans.org/dev/javadoc/index.html
#javac API - http://java.sun.com/javase/6/docs/technotes/guides/javac/index.html
#Larry Koved's excellent paper on access rights analysis for java - [http://portal.acm.org/ft_gateway.cfm?id=582452&type=pdf&coll=GUIDE&dl=GUIDE&CFID=634220&CFTOKEN=95929885 Access Rights Analysis for Java]

[[Category:MQP]]