MQP:Rule to Resource Mapping

From JimboWiki
Jump to: navigation, search


MQP Navigation

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 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:

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


And this is what the rule for RuntimePermissions looks like:

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


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.

Resource Model