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

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

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.

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

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)
      • Parameters - A container for parameters to actions
        • 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)
      • 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.

Model Implementation

XML Description

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

Java Classes

Resource Model