Merge "Add modal operators to policy language"
This commit is contained in:
commit
c672299a72
|
@ -0,0 +1,198 @@
|
|||
..
|
||||
This work is licensed under a Creative Commons Attribution 3.0 Unported
|
||||
License.
|
||||
|
||||
http://creativecommons.org/licenses/by/3.0/legalcode
|
||||
|
||||
==========================================
|
||||
Add modal operators to policy language
|
||||
==========================================
|
||||
|
||||
https://blueprints.launchpad.net/congress/+spec/modal-operators-for-policy
|
||||
|
||||
To express access control policies and reactionary enforcement policies, we
|
||||
need modal operators like 'execute' and 'permit' added to the language. Modal
|
||||
operators are identifiers that apply to literals or rules in the language and
|
||||
hence cannot be encoded (naturally) without special syntactic support.
|
||||
|
||||
|
||||
Problem description
|
||||
===================
|
||||
|
||||
Example policy fragments that are enabled by this change:
|
||||
|
||||
1) Reactionary policies: describing what actions/API-calls Congress should
|
||||
execute and when.
|
||||
|
||||
execute[nova:disconnectNetwork(vm, net)] :-
|
||||
nova:virtual_machine(vm),
|
||||
nova:network(vm, net),
|
||||
bad_network(vm, net)
|
||||
|
||||
2) Access control policies: describing when other components are permitted
|
||||
to execute certain actions/API calls.
|
||||
|
||||
permit[nova:disconnectNetwork(vm, net)] :-
|
||||
nova:owner(vm, owner),
|
||||
role(owner, 'admin')
|
||||
|
||||
3) Action descriptions: describing the effects of an action
|
||||
|
||||
delete[nova:network(vm, net)] :-
|
||||
execute[nova:disconnectNetwork(vm, net)]
|
||||
|
||||
|
||||
Proposed change
|
||||
===============
|
||||
|
||||
This change requires modifying the grammar to so that the constructs above
|
||||
are permitted. To do this, we would want to make the definition for 'rule'
|
||||
into something like the following.
|
||||
|
||||
rule ::= modal_list COLONMINUS modal_list
|
||||
modal_list ::= modal (COMMA literal)*
|
||||
modal ::= literal | ID LBRACKET literal RBRACKET
|
||||
|
||||
We also need to change compile.py:Literal class to have a field 'modal' that
|
||||
is either None or is an ID (string).
|
||||
|
||||
We also need to change the unifier so that it checks the 'modal' field when
|
||||
doing unification.
|
||||
|
||||
Finally we need to introduce functionality so that we can ask for all
|
||||
x such that execute[x] is true in the current state. One option is to
|
||||
construct a special function in the Runtime; another option is to expand the
|
||||
definition of a modal so that it can take a variable, such as shown below,
|
||||
and modify the unifier and runtime.py:TopDownTheory.top_down_eval routines
|
||||
appropriately.
|
||||
|
||||
modal ::= literal | ID LBRACKET literal RBRACKET | ID LBRACKET ID RBRACKET
|
||||
|
||||
|
||||
Alternatives
|
||||
------------
|
||||
|
||||
Today the way we write action descriptions is by using + and - as suffixes
|
||||
on table-names to denote insert and delete respectively. This
|
||||
does not extend well to other modals like 'execute' and 'permit'.
|
||||
|
||||
The prototype code already in place assumes it can identify what is to be
|
||||
'execute'd and what is to be 'permit'ed based on the policy the rules
|
||||
reside in. Having separate policies for implementing this functionality
|
||||
is a poor solution because multiple policies ought to be able to represent
|
||||
multiple policy authors' contributions to policy--a single policy ought to
|
||||
be able to include reactive policy, access control policy, error policy,
|
||||
and action-descriptions.
|
||||
|
||||
In addition, the functionality we currently use for dealing with
|
||||
action-descriptions while implementing simulation uses the 'consequences'
|
||||
construct to compute all of the literals inserted and deleted upon execution
|
||||
of a given action. The 'consequences' functionality is computationally
|
||||
expensive in that it computes the contents of all tables in the policy. Once
|
||||
a single policy contains more than simply the action-descriptions, we cannot
|
||||
afford to use the 'consequences' functionality.
|
||||
|
||||
Policy
|
||||
------
|
||||
|
||||
See use cases above.
|
||||
|
||||
Policy Actions
|
||||
--------------
|
||||
|
||||
N/A
|
||||
|
||||
Data Sources
|
||||
------------
|
||||
|
||||
N/A
|
||||
|
||||
Data model impact
|
||||
-----------------
|
||||
|
||||
None since rules are stored as strings in the DB.
|
||||
|
||||
|
||||
REST API impact
|
||||
---------------
|
||||
|
||||
None since policy snippets are passed as strings.
|
||||
|
||||
|
||||
Security impact
|
||||
---------------
|
||||
|
||||
None
|
||||
|
||||
Notifications impact
|
||||
--------------------
|
||||
|
||||
None
|
||||
|
||||
Other end user impact
|
||||
---------------------
|
||||
|
||||
None
|
||||
|
||||
Performance Impact
|
||||
------------------
|
||||
|
||||
None
|
||||
|
||||
Other Deployer Impacts
|
||||
----------------------
|
||||
|
||||
None
|
||||
|
||||
Developer Impact
|
||||
----------------
|
||||
|
||||
None
|
||||
|
||||
|
||||
Implementation
|
||||
==============
|
||||
|
||||
Assignee(s)
|
||||
-----------
|
||||
|
||||
Primary assignee:
|
||||
<launchpad-id or None>
|
||||
|
||||
Other contributors:
|
||||
<launchpad-id or None>
|
||||
|
||||
Work Items
|
||||
----------
|
||||
|
||||
- Modify grammar as described above
|
||||
- Change parser to read in new grammar
|
||||
- Change runtime to properly unify with modals
|
||||
- Add modal-level queries, e.g. find all x such that execute[x]
|
||||
|
||||
|
||||
Dependencies
|
||||
============
|
||||
|
||||
N/A
|
||||
|
||||
Testing
|
||||
=======
|
||||
|
||||
Unit tests are sufficient. Ensure that the new syntactic constructs
|
||||
can be used anywhere and that the runtime produces the proper results
|
||||
when the new syntactic constructs are in place.
|
||||
|
||||
Documentation Impact
|
||||
====================
|
||||
|
||||
End-user documentation is not necessary for this change. But documentation
|
||||
will be necessary for the functionality that uses this change, e.g.
|
||||
the simulation() docs will change to describe using insert[]/delete[] instead
|
||||
of +/- suffixes.
|
||||
|
||||
|
||||
References
|
||||
==========
|
||||
|
||||
None
|
Loading…
Reference in New Issue