Documentation for
the Structured Policy Language Interface

Introduction:
This document explains the basic components of the GUI, the translation between the GUI and the underlying logic, and possible enhancements for the next version of the software. Objects, subjects, actions, and parameters are used to model the system to which the policies and consequences apply. The policies state which actions are permitted and which are forbidden for a given subject and object under a set of parameter relations. The consequences describe how the model changes when an event occurs. The translation converts policies, consequences, and a subset of the subject relations into the logic. Future work includes analyzing the translated formulas.

Basic Components:
Objects:
An object is any entity that actions can manipulate. Examples include a single file, a digital book with both text and images, and a collection. Although a subject (an entity that can perform actions) may be associated with one or more objects, a subject is not an object. This allows the user to specify which subjects can be manipulated, by specifying which subjects are associated with objects.

An object is defined in the GUI by assigning it a unique name, specifying any attributes that it has, and listing the objects that it contains. While it is tempting to define the name of an object to be its location, this may not be applicable to digital objects that have components dispersed throughout the network. Since location may not be appropriate, the GUI allows an object's name to be any string that is not already used to describe another object or an attribute of an object. An attribute is a string such as "Created: Oct/10/00" or "private". By referring to objects by their attributes, a single policy or consequence can apply to several objects including ones that did not exist when the policy or consequence was created. Unfortunately, an attribute cannot be used to specify relationships between entities and notions like "Author: Sandy" and "Author: Joe" are the same 'type' of attribute cannot be captured. Future versions of the software will need to address these deficiencies. In the meantime, an explicit field is given to express the frequently-used concept that an object contains other objects.

Subjects:
There are 2 types of subjects; principals and roles. A principal is any entity that can perform actions. A role is an identity that one or more principals may adopt. For example, Charlie is a principal. CS Faculty and Head of CS Dept. are roles.

A subject is defined in the GUI by assigning it a unique name. If a subject is not chosen to be a role (by checking the isRole box) then it is assumed to be a principal. The 'Member of' field lists the roles that are associated with the subject. For example, Charlie may be a member of the CS Faculty and the Head of the CS Dept. Although a subject cannot be listed as a member of a principal (i.e. the CS Faculty cannot be a member of Charlie), a role may be a member of other roles. The interpretation of a role, R1, being a member of a second role, R2, is that every principal that is a member of R1 is also a member of R2. This allows the user to express ideas such as the Head of the CS Dept. must be a member of the CS Dept.

Actions:
An action is any entity that a subject can invoke to manipulate an object. Actions are defined in the GUI in the same way as objects, except that there is no 'contains' field.

In the original GUI design, ad-hoc polymorphism was supported by allowing multiple actions to have the same name providing that they applied to different objects. This feature was removed, because it lead to undesirable interdependencies between objects and actions. The effect, however, can be approximated through the naming process. For example, a user could define an action named "/page/turn" and another action named "/volume/turn".

Parameters:
Parameters describe the system's state. They are particular useful when an entity, such as an expiration date, could be stored with various components, but doing so would imply a particular defense mechanism. Parameters are currently implemented as variables or constants with an integer value. Consequences are used to express how a parameter's value changes. This implementation is not adequate. Parameters need a better mechanism for expressing relationships; one that is more flexible and more intuitive. Also, the range of values that a parameter can have should be bounded to facilitate reasoning about the policies. These issues will be addressed in the next version of the software.

Policies:
A policy states the circumstances under which an action may or may not be invoked. In the GUI, a policy states if a subject is permitted or forbidden to do an action to an object under a possibly empty set of conditions. A condition is a comparison (less than, equal to, or greater than), between the values of 2 parameters. In place of a specific subject, action, or object, a list of roles or attributes may be given. A policy applies to any component that has every role or attribute in the relevant list. If a specific component is listed along with a set of roles or attributes, then the policy only applies to that component and only if that component meets the other listed criteria. Future versions of the software will replace the list separator (currently a semi-colon) with the more intuitive keyword AND. The keyword OR will also be added.

Consequences:
A consequence defines how the model changes when an event occurs. In the GUI, an event is when a subject invokes an action on an object under a possibly empty set of conditions. The consequence of an event could be any combination of the following types of changes:

• actions are performed
• parameters are assigned new values
• parameters are created
• objects acquire, possibly new, attributes
• objects are created with, possibly new, attributes
• principals gain new memberships

The GUI predefines a parameter called time which is used to express that the changes occur in the next time step. This will no doubt be revised when the problems with parameters are addressed. The GUI also defines the keywords 'doer' and 'same' so that the consequence can refer to the particular principal (doer), action (same), and/or object (same) involved in the event.

The ability to create new attributes and parameters will be restricted in future versions of the software, once the other issues with these components are addressed.

Translation:
The translator creates a clause in the logic for:

1. each subject that is both a role and a member of other roles
2. each policy
3. each consequence

The translator produces:
forall time t, forall principals p, r(p, t) => r1(p, t) AND r2(p, t) AND r3(p, t) AND... AND rn(p, t)

Note: The above example is not quite right, in that the GUI requires each member to be listed as opposed to a '...'. Also, each element in the Member of field is assumed to be of type role. The GUI will return a bad format error, if this is not the case.

2. Given the following input into the GUI:

The tranlator produces:

• If every subject is a role, every action is an action attribute, and every object is an object attribute, then the translation is:
  forall time t forall principals p forall actions act forall objects obj s1(p, t) AND s2(p, t) AND...AND sw(p, t) AND a1(act, t) AND a2(act, t) AND ax(act, t) AND o1(obj, t) AND o2(obj, t) AND oy(obj, t) AND p1(t) * p1'(t) AND p2(t) * p2'(t) AND ... AND pz(t) * pz'(t) => NOT permitted(p, act(obj), t)

  Re-written in a nicer form:
  

  

• If si is a principal, aj is an action, and ok is an object then the translation is:
  forall time t s1(si, t) AND ... AND s(i-1)(si, t) AND s(i+1)(si, t) AND ... AND sw(si, t) AND a1(aj, t) AND... AND a(j-1)(aj, t) AND a(j+1)(aj, t) AND ... AND ax(aj, t) AND o1(ok, t) AND ... AND o(k-1)(ok, t) AND o(k+1)(ok, t) AND ... AND oy(ok, t) AND p1(t) * p1'(t) AND p2(t) * p2'(t) AND ... AND pz(t) * pz'(t) => NOT permitted(s1, aj(ok), t)

  Re-written in nicer form:
  

  

As in the previous example, the ellipses are not valid syntax. The * in the conditionals is also invalid. Legal comparitors are '<', '=', and '>'. The GUI returns an error if any component is undefined. The GUI also returns an error if 2 principals, 2 actions, or 2 objects are listed, since these conditions could never be met. If the policy permits instead of prohibits, then the NOT is removed. The translations for the various type combinations (such as all subjects are roles, but aj is an action and ok is an object) follow from the given translations.

3. Given the following input into the GUI:

With additional consequences:

The translator produces:

• If every subject is a role, every action is an action attribute, and every object is an object attribute then the translation is:
  forall time t forall principals p forall actions act forall objects obj s1(p, t) AND s2(p, t) AND...AND sw(p, t) AND a1(act, t) AND a2(act, t) AND ax(act, t) AND o1(obj, t) AND o2(obj, t) AND oy(obj, t) AND p1(t) * p1'(t) AND p2(t) * p2'(t) AND ... AND pz(t) * pz'(t)AND Did(p, act(obj), t) => Did(pr, a(o), t+1) AND Did(p, act(obj), t+1) AND at1(o, t+1) AND at2(o, t+1) AND ... AND atn(o, t+1) AND at1'(obj, t+1) AND at2'(obj, t+1) AND ... AND atn'(obj, t+1) AND par2(t+1)=int AND par1(t+1)=par1(t) + 1 AND r1'(p, t+1) AND r2'(p, t+1) AND...AND r3'(p, t+1) AND r1(pr, t+1) AND r2(pr, t+1) AND...AND r3(pr, t+1)

  Re-written in a nicer form:
  

  

• If si is a principal, aj is an action, and ok is an object then the translation is:
  forall time t s1(si, t) AND... AND s(i-1)(si, t) AND s(i+1)(si, t) AND...AND sw(si, t) AND a1(aj, t) AND... AND a(j-1)(aj, t) AND a(j+1)(aj, t) AND...AND ax(aj, t) AND o1(ok, t) AND ... AND o(k-1)(ok, t) AND o(k+1)(ok, t) AND ... AND oy(ok, t) AND p1(t) * p1'(t) AND p2(t) * p2'(t) AND ... AND pz(t) * pz'(t)AND Did(si, aj(ok), t) => Did(pr, a(o), t+1) AND Did(si, aj(ok), t+1) AND at1(o, t+1) AND at2(o, t+1) AND ... AND atn(o, t+1) AND at1'(ok, t+1) AND at2'(ok, t+1) AND ... AND atn'(ok, t+1) AND par2(t+1)=int AND par1(t+1)=par1(t) + 1 AND r1'(si, t+1) AND r2'(si, t+1) AND...AND r3'(si, t+1) AND r1(pr, t+1) AND r2(pr, t+1) AND...AND r3(pr, t+1)

  Re-written in nicer form:
  

  

Although there is no limit to the number of changes that can occur to the model following an event, the above translation covers every type of change. Some typing checks still need to be added, but any action that results from an event should have a single principal, action, and object listed (listing roles or attributes is not legal syntax.) A parameter cannot be changed twice in the same consequence. A principal may change membership due to an event, but roles are assumed to be static. When changing an object's attributes, a single object must be listed, although a list of attributes are allowed.

Future Work:
Fundemental Issues:

Although the individual components model a generic security system well, the 'glue' that expresses the relationships between components is inadequate. Both attributes and parameters must be re-done to allow policies such as the following to be expressed:

• Any student who is a TA for a course may alter that course's gradebook.

  Currently, a rule must be written for each course. For example:
  foreall time t, forall principals p, forall objects obj,
  TA_CS676(p, t) AND gradebook(obj, t) AND CS_676(obj, t) => Permitted(p, write(obj), t)

  We want the rule to be something like:
  forall time t, forall principals p, forall objects obj, forall ?forms? course
  course(p, TA, t) AND course(obj, gradebook, t) => Permitted(p, write(obj), t)

  The next version of the interface must define the syntax and semantics for structures like course.

• If a user pays the fee, then that user may access the object for x time units

  The issue here is that we want to create a new parameter that associates a time (the expiration date) with a particular user and object. Although the name of the parameter could be munged to support this, its not a good hack.

The time concept should also be re-examined. For consequences to make sense, there needs to be a notion of before and after; however, policies that use unbounded time are not easy to reason about. Therefore, we need to look at what restrictions can be made to simplify reasoning without sacrificing our ability to express common policies.

Currently, clauses in the formula are stored in a big hashtable and each policy, consequence, and subject node mantains a copy of its clause, sending updates to the hashtable as needed. We need to modularize the clauses. In addition, any component that is effected by a clause should have either a pointer to it or a copy of it.

At some point, we will need to develop a mechanism for determining who can view and/or change the entries in the GUI.

Details:
The following is an incomplete list of features and fixes that need to be implemented.

• Replace the list separator, ;, with the keyword AND. Also, add the keyword OR
• Decide what components support NOT and add the keyword where appropriate.
• Finish implementing type checking.
• Fix terminology. Both 'consequence' and 'policy' are overloaded.
• Add keyword ALL to refer to all components of a certain type.
• Allow users to make multiple changes without re-invoking the panel.
• Allow the premise of consequences to be changed, as well as the results.
• Allow graphical selection of attributes on all relevant panels.
• Clean-up error and status messages.

Questions concerning this project should be sent to Vicky Weissman.