\section{Introduction}
\label{sec:whitePaper}

The Structured Policy Command Language (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 both specialized domain requirements 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.

\vspace{5mm} 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 simplifies the task of policy specification
and separates 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 systems programmers or
application architects.

\vspace{5mm} 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
\textit{specifying}, \textit{enforcing}, and \textit{revising}
requirements. Any system built to handle policy should provide
specification, enforcement, and revision mechanisms.

\subsection{Background}
\label{sec:whitePaper_background}

\subsubsection{What is Policy?}
\label{sec:whitePaper_background_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.

\vspace{5mm} 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).

\vspace{5mm} 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.

\subsubsection{What are some examples of current policy mechanisms?}
\label{sec:whitePaper_background_example}

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
weaknesses: 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.
The default file controlling Java policy (if a SecurityManager is
invoked in the current JVM) is located in the
JAVA\_HOME/jre/lib/security/java.policy file, and has a series of
"grant blocks" that allow a set of classes to have a predefined
set of permissions (essentially an arbitrary collection of
statements permitting the set of classes to invoke certain
language functions). The Java policy file syntax is roughly the
following:

\begin{tabbing}
grant \=SOME\_CLASSES \{\+\\
    permission SOME\_PERMISSION ``args";\\
    permission ANOTHER\_PERMISSION ``args";\-\\
\}\\
\end{tabbing}

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.

\vspace{5mm} 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.

\vspace{5mm} 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.

\subsection{SPCL Features}
\label{sec:whitePaper_feature}

\subsubsection{SPCL Highlights}
\label{sec:whitePaper_feature_hightlight}

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

\vspace{5mm} A common pattern for specification is of the form:

\vspace{5mm} \{command\} \{principal\} performs \{action\} on
\{object\} when \{conditions\}

\vspace{5mm} 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.

\subsubsection{SPCL Goals}
\label{sec:whitePaper_feature_goal}

The SPCL has three primary goals that correspond to the essential
components of a policy mechanism. SPCL must support policy
specification, enforcement, and revision.

\vspace{5mm} First, in order to support \textbf{policy
specification}, the SPCL should provide 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 and ease of specification is expected to increase
because of this goal.

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.

\vspace{5mm} Second, in order to support \textbf{policy
enforcement}, 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.

\vspace{5mm} Third, to support \textbf{policy revision} SPCL
should have some idea of system lifecycle. Most policy is
implemented implicitly 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.

\subsection{Example Policy Domains}
\label{sec:whitePaper_domain}

\subsubsection{Authentication \& Authorization}
\label{sec:whitePaper domain_AA}

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

Reject any user who provides the wrong password.

Reject any user who has three successive bad login attempts.

\subsubsection{Firewall Rules \& Packet Filtering Filtering}
\label{sec:whitePaper_domain_firewall}

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:

\vspace{5mm} ipchains -A input -j ALLOW -p tcp -s 0.0.0.0/0 -d
www.mycompany.com 80

\vspace{5mm} to express a policy of:

\vspace{5mm} Allow anybody to access my webserver over TCP on port
80.

\vspace{5mm} Note the natural structure of the command, however:

\vspace{5mm} Add an `ALLOW' rule to my `input' policy for a
principal `0.0.0.0/0' on my object `www.mycompany.com' with the
condition that the protocol is TCP.

\subsubsection{BGP}
\label{sec:whitePaper_domain_bgp}

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

\subsubsection{House Monitoring System}
\label{sec:whitePaper_domain_house}

The application that SPCL focuses on for motivating examples is a
home monitoring system. This system is a policy-aware control
application 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.

\subsection{SPCL Language Primitives}
\label{sec:whitePaper_language}

The language is a declarative-style specification language; it is
not an imperative 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
primitives (some of which directly translate to reserved words):

\begin{list}{$\bullet$}{}
\item zone - an area containing many policy definitions generally
under 1 administrative domain.

\item policy - a policy definition

\item principal - an object in the system that acts autonomously

\item object - an object in the system that is acted upon

\item group - a group of principals

\item action - a flexible but concrete notion of what a principal
attempts to get permission for

\item rule - a regular expression for a class or group of actions

\item condition - an expression to be satisfied in order for the
policy engine to respond to the user.

\item meta-action - the action taken by the system in response to
a principal's request to perform an action on an object

\item constraint - reserved for future use

\item requirement - reserved for future use

\item assertion - reserved for future use

\item demand - reserved for future use

\item consequence - reserved for future use
\end{list}

The language operates with a data model that focuses on events
that affect a three-tiered map of principals, groups, and objects.
Events can query the state of the map (a relationship between map
objects) or alter the state of the map (change the current
policy), and three precedence levels: user, group, and default
group. The policy engine will match rules beginning with the
specific user, then against groups the user belongs to, and
finally against the default group.

\subsection{Conclusions}
\label{sec:whitePaper_conclusion}

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. Meeting these
goals provides a policy mechanism that supports the specification,
enforcement, and revision of policy.

