|
The SPCL is designed to address a number of issues found in policy and permission systems. The notion of a policy is central to the design and operation of most complex systems. Because the concept of policy is a nebulous one, efforts to formalize it have suffered from specialization to the domain and the inherent complexity of policy decisions. The SPCL is an effort to provide a domain-independent language for specifying policy requirements, principals, rules, and actions in a lightweight syntax with semantics as close to natural expression as possible, in order to avoid esoteric and complex programming constructs. If need be, SPCL can be compiled to another form, such as that supported by the Keynote trust management system. Current policy systems are either built into a system (making them hard to adjust or replace) or too course-grained to be effective and easy to use. There is a clear need for a policy language that greatly simplfies the task of policy specification and seperates policy specification from policy implementation. In addition, policy is often specified by non-programmers, so any language should be sufficiently easy to learn while retaining powerful specification abilities for real programmers. |
What is Policy?Policy is generally considered to be a plan or course of action intended to influence decisions or outcomes. A policy is a set of guiding principles whereby some outside agency can match its current environment or task with the guidelines in the policy and proceed with a course of action. Policy decisions range from very simple (accept or reject access request N) to very complex (never let the dogs outside unless someone is home and their collars are on and the electric fence is on and it is not raining) to extremely complex (allow half of this customer's address space to advertise their prefix with us, but do not let their traffic use us as a transit network, unless the lawyers say otherwise). Policy is ubiquitous in computing systems, and is often implicitly coded into a system's structure by functional requirements, language features, and design decisions. Policy is not easily managed because it is so high-level and rarely translated to formal program semantics. It is important to note that policy is not merely access control. Policy is essentially about expressing a want or desire. Therefore, we can conclude that policy is about specifying, enforcing, and revising requirements. What are some examples of current policy mechanisms?A language-specific attempt to provide a policy mechanism is the Java Policy and Permissions objects. While the Java approach is a fairly good attempt, it suffers from two major weakness: difficulty of use and lack of a fine-grained approach. The file used to control the policy rules in the currently running JVM is often ignored because it is an additional layer of complexity in the design, construction, and testing of a system. In addition, the default policy mechanism is very course-grained and although it is easily extensible, does not lend itself to quick analysis of any given software. Even though there are a number of permissions to legislate,
this set of permissions is not provably complete or precise enough for
many complex applications. Not unsurprisingly, this lack of fine-grained
permission managament doesn't overtly hinder Java applications running
without a policy, mainly due to the safety features built into the language.
The default file controlling Java policy (if a SecurityManager is invoked
in the current JVM) is located in the
Another effort to specify a policy language is the Web Services Security Policy Language by IBM, Microsoft, Verisign, and RSA. However, this policy language is domain-specific and meant to provide an XML-grammar based mechanism for policy assertions for web services. Yet another system that involves policy specification is KeyNote, a trust management and policy system. While KeyNote is a powerful mechanism, its policy specification syntax is not for the faint of heart. The Ponder Policy Specification Language is a method for specifying security constraints and mapping them onto certain principals in the system. |
SPCL HighlightsSPCL's primary two features are an object-oriented-like command language (and compiler) and a PolicyEngine interpreter acting as an oracle to a number of other systems. SPCL's syntax is closest in appearance to a mixture of Java and SQL. The PolicyEngine should be thought of as a VM for policy. A policy is specified in the SPCL syntax, parsed, and then translated to a form suitable for input to the PolicyEngine. The specification for the PolicyEngine is platform-independent, so it can be implemented for any target platform. After parsing and construction, it then loads and interprets the policy. The PolicyEngine has a simple protocol for asking questions about the running policy (in SPCL) as well as loading new policies in, updating current policy, and retiring outdated policy. SPCL GoalsThe SPCL has three primary goals. First, the SPCL should support a syntax that is close to the natural language method of specifying policy rules and permission constraints. SPCL is necessarily a high-level language. Ease of use is expected to increase because of this goal. For example, an SPCL command should be close in syntax to an original thought or expression of desire in the natural language:
Is preferable (for a user) to an alternate syntax:
public class DogMonitor implements Runnable{
Environment env=null;
public DogMonitor( Environment env ){
this.env=env;
}
public void run(){
Weather currentWeather = env.detectWeather();
Request request = env.currentRequest();
if( currentWeather.getState() == Weather.RAIN &&
request.letDogsOutside() ){
env.preventDogsFromGoingOutside();
}else{
//evalutate other combinations of request and environment
}
}
}
A list of generic motivating example policies reveals a common pattern:
{command} {principal} performs {action} on {object} when {conditions}
In the absence of natural language processing support for policy (which may be rectified by
research conducted by the Navy), this pattern of principals,
actions, and objects very naturally suggests itself. SPCL, like SQL, is a language that seeks
to be easy to use while remaining focused, formal, and powerful.
The important point here is the focus on the user of the system. The user is actually writing the policy as they express their desires. However, they should have to do a very small amount of work to express their policy formally, and this work should not involve strange syntax or traditional source code structures a 'programmer' would know how to manipulate. This requirement is aided by the simple command-oriented nature of policy. Most policies have little hierarchical structure; they specify a set of actions under given conditions. Second, the SPCL should have semantics that are not costly to interpret, have little or no side effect other than the intended goal of the policy, and are domain independent. This goal supports both ease of use, simplicity of interpretation, and broad application. SPCL is not merely a method of controlling access with a binary grant or refuse. Third, SPCL should have some idea of system lifecycle. Most policy is implemented implictely or statically in program code and is difficult and expensive to change. Policy needs to be dynamically updateable, and should respond to a lifecycle model. Knowledge of the lifecycles for both the policy and the systems the policy governs will allow the PolicyEngine to make informed and powerful decisions. Users must be able to create, alter, and retire their policy easily, without a costly impact on the rest of the system. |
Authentication & AuthorizationAuthentication and authorization is the most simple and common sort of policy implementation in systems today. SPCL is useful for this base case of binary accept or reject decisions, such as those faced during a login procedure or access request. An example policy for authentication is:
and is probably implemented in an esoteric and complex amount of code involving file reading or database lookups. Firewall Rules & Packet FilteringFiltering IP packet traffic is another application of policy. The network administrator desires traffic into and out of her network to have certain characteristics. Packet filters are often simple tables of rules. Traffic is pattern matched against the table, and the specified action is performed. A common tool for packet filtering is the Linux tool ipchains and has syntax like the following:
to express a policy of:
Note the natural structure of the command, however: BGPBGP, or Border Gateway Protocol (v4), is the protocol used on the Internet to advertise routes between computers. BGP does not calculate the optimal path (shortest path) for traffic; rather, BGP calculates the best path for traffic, where best is defined by an arbitrary policy: legal and business agreements. House Monitoring SystemThe application that SPCL focuses on for examples is a home monitoring system, a policy-aware control system for home appliances. Homes and families have many arbitrary rules that govern use of various appliances and tasks that need to be done in order for the home to run smoothly. |
Here is an example .spcl file.
|
/**
* trust must be organized between zones; zones may
* contain more than one policy definition.
*/
zone home;
policy MyPolicy{
default{
DENY *;
ALLOW "channel 5" BY Mom,Dad,Ken ON "tv" WHEN (time="5:00pm") DURING run() AND NOTIFY Mom;
}
group parents{
ALLOW * ON *;
}
group children{
DENY * ON *;
}
principal Mom{
public key = "ldap://192.168.4.240/mom/keys/pub.key";
ALIAS wonderWoman, ADMIN;
GROUPS parents,students;
}
principal Dad{
ALLOW *;
ALIAS father;
GROUPS parents;
}
principal Ken{
ALLOW "GET /index.html HTTP/1.1" ON webserver WHEN (state="summer" AND time>"1800") AND {NOTIFY logger};
ALLOW "open door" ON "fridge";
ALLOW "play" ON "outside" WHEN (state="sun shining" AND ken.homework="done") AND
{ if( time>1400 )
NOTIFY Police;
else
NOTIFY Mom;
};
GROUPS students,children;
}
object fridge{
url = "appliance://FF::AB:34:22/kenmore1/";
actions{
rule rule1 = "ls [a..z]*";
rule1.meta-action = "NOTIFY Mom";
rule1.default-action = "DENY";
/**
* <rule name="rule1" meta-action="NOTIFY Mom" default="DENY">ls [a..z]*</rule>
*/
}
}
object webserver{
url = "http://www.thesmiths.home:80/";
actions{
rule rule1 = "GET [a..z]*.html HTTP/1.[1|0]";
rule1.meta-action = "NOTIFY Mom";
rule1.default-action = "DENY";
}
}
}
SPCL is defined in terms of actions that a principal (an autonomous object in the system) can take. These actions are performed on some object with some conditions during some lifecycle phase. Keywords are case-insensitive. Thus "ALLOW"="allow" and "principal"="PRINCIPAL" |
|
The language is a declaritive-style specification language; it is not an imperitive one. The language does allow for traditional branching control flow (if..then..else) even though its model of computation is primarily event-based. It has the following primatives:
There are three precedence levels:
|
|
SPCL is a language meant to simplify the expression of arbitrary policy. The primary goals of SPCL is to formalize the expression of policy, separate the specification of policy from the implementation of the system the policy governs, and provide the system with a lifecycle-aware policy mechanism. |