MQP:Rule to Resource Mapping - Revision history

Jpolitz: /* Java Classes */

2008-09-26T18:08:23Z

‎Java Classes

Jpolitz: /* XML Description */

2008-09-26T17:58:59Z

‎XML Description

Jpolitz at 17:43, 26 September 2008

2008-09-26T17:43:07Z

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

2008-09-26T17:25:46Z

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

Jpolitz: /* Resource to Permission Data Model */

2008-09-26T17:21:48Z

‎Resource to Permission Data Model

J at 01:15, 23 September 2008

2008-09-23T01:15:50Z

Jpolitz: /* Resources */

2008-09-16T21:01:46Z

‎Resources

Jpolitz: /* Resources */

2008-09-16T20:57:53Z

‎Resources

Jpolitz: /* Resource to Permission Data Model */

2008-09-16T19:25:11Z

‎Resource to Permission Data Model

Jpolitz: /* Resource to Permission Data Model */

2008-09-16T19:24:05Z

‎Resource to Permission Data Model

← Older revision		Revision as of 18:08, 26 September 2008
Line 168:		Line 168:

	===Java Classes===		===Java Classes===
		+
		+	This is slightly out of sync with the newer version of the model.

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

@@ Line 116: / Line 116: @@
 ==Model Implementation==
 ===XML Description===
-The permission and resource mapping is persisted in an XML file. (more description to come)
+The rule and resource mapping is persisted in an XML file.
 ===Java Classes===
 [[Image:ResourceModel.png|frame|Resource Model]]

@@ Line 53: / Line 53: @@
 **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.
+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."
-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.
+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.
 ==Permissions==
-Permissions have a more low-level representation based on the classes they originate from, such as:
+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.
 *java.io.FilePermission
 *java.net.SocketPermission
@@ Line 68: / Line 77: @@
 *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.
+Some permission classes cover multiple resources and many actions.  Some actions have multiple specific permission rules required.
-==Mapping from Resources to Permissions 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:
-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 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 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.
+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===

@@ Line 78: / Line 78: @@
 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===
+===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.
@@ Line 86: / Line 86: @@
 ***'''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
+****'''Action 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)
+*****'''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)
-****'''Permissions to Grant''' - A container of permission classes and parameters to grant to allow this action (one for each action present)
+****'''Rules to Apply''' - A container of rules to apply 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)
+*****'''Applied Rule''' - A description of a security rule requirement for this action and parameters (many for each rule container)
-****'''Implied by''' - Container describing ways to imply this action (one for each action present)
+*'''Rule''' - Top level container for a Rule (one for each Rule 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
+**'''Type''' - The type of the rule.  For instance, in the Java security standard, the type is Permission.
-**'''Parameters''' - A container for parameters to create the permission object
+**'''Name''' - The name of the rule.  This is a unique identifier within each rule type.
 ***'''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)

← Older revision		Revision as of 01:15, 23 September 2008
Line 102:		Line 102:
	==Fitting Developer Specified Resources Together with Permission Requirement Analysis==		==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.		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]]

← Older revision	Revision as of 17:25, 26 September 2008
(No difference)

← Older revision		Revision as of 21:01, 16 September 2008
Line 54:		Line 54:

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

@@ Line 4: / Line 4: @@
 ==Resources==
-In Java, there are many resources that can be protected including:
+There are a number of broadly-defined resource categories that programs could need to access and which need to be secure:
-*The file-system
-*Socket connections
+*File system
-*Java system properties
+*Connection resources (Socket connections, for example)
-*Graphics output
-*Class loaders
-*Java reflection system
 *Java security system
 For each resource, there are actions associated.  For instance:
-*The file-system
+*File-system
-**Read
+**Create, read, write, execute, and delete particular files
-**Write
+*Connections (socket and other)
-**Create new
+**Listen, accept, and connect
-*Socket connections
+**Handle cookies and other sensitive data
-**Listen
+*Java system management
-**Accept connection
-**Create connection
-*Java system properties
 **Read specific properties
-*Graphics output
+**Set properties
-**?
+**Override default behaviors, like System.in/out, default exception handlers, shutdown hooks
 *Class loaders
 **Create new class loaders
 **Load classes
 *Java reflection system
 **Access private methods
 **Create reflected objects
 *Java security system
-**Access SecurityManager
+**Get/set/alter SecurityManager
-**Replace SecurityManager
+**Create AccessControlContexts
 ==Permissions==

@@ Line 58: / Line 58: @@
 ===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.
+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)