MQP:Rule to Resource Mapping

MQP Navigation ▼ MQP ► MQP-Design ► MQP-Prototypes ► MQP-Research   Main   Project Overview

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

In Java, there are many resources that can be protected including:

• The file-system
• Socket connections
• Java system properties
• Graphics output
• Class loaders
• Java reflection system
• Java security system

For each resource, there are actions associated. For instance:

• The file-system
  • Read
  • Write
  • Create new
• Socket connections
  • Listen
  • Accept connection
  • Create connection
• Java system properties
  • Read specific properties
• Graphics output
  • ?
• Class loaders
  • Create new class loaders
  • Load classes
• Java reflection system
  • Access private methods
  • Create reflected objects
• Java security system
  • Access SecurityManager
  • Replace SecurityManager

Permissions

Permissions have a more 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. Certain combinations of permission grants can result in other permissions being implicitly granted based on logic in the permission check.

Mapping from Resources to Permissions and Back

Some sort of description of the relationship between a resource with its actions and a permission class would be developed. Important things to explain in this model include:

• A description of the resource and all its actions
• What permission class(es) 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 permission set. Given a permission set, we should be able to do reverse lookups to find the resource grant implications, including implicit resource access grants.

Resource to Permission Data Model

A very hierarchical structure will be best. It will 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)
      • Permissions to Grant - A container of permission classes and parameters to grant to allow this action (one for each action present)
        • Permission Reference - A description of a permission requirement and parameters (many for each permission grant container)
      • Implied by - Container describing ways to imply this action (one for each action present)
        • Implied - A description about a set of actions that would result in this action being implied (many for each action present)
• Permission - Top level container for a Permission (one for each permission present)
  • Description - A human readable description of what the permission is (one for each permission present)
  • Fully Qualified Class Name - The FQN of the class associated with the permission
  • Parameters - A container for parameters to create the permission object
    • 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.