[Monotone-devel] Policy user model

[Timothy Brownawell]

I propose that in trying to figure out how to handle policy branches,
and disagreements, and such, we have been thinking at the wrong level of
abstraction. We've been talking about "what can the history graph look
like" and "does this way of handling it make sense", and trying to build
a sensible behavior from there. But what we need first is a model of
"what results are we (the users) trying to achieve", and the necessary
properties of the system (and then the implementation) should follow. We
need a User Model.

The main interesting thing that seems to come from this is that
revisions in the policy branch shouldn't be trusted/distrusted as a
whole, but each statement should be trusted/distrusted individually.


What we have (laws of nature)
-----------------------------

In general, a statement looks like: "Alice says that Bob is allowed to X
under conditions Y.". Each statement has a principal (Alice), a subject
(Bob), an action (X), and a condition (Y). The policy is a collection of
statements, changing over time. It is not in general possible to know
the order in which statements were made, unless one statement makes
explicit mention of another (earlier) statement. The available actions
(X) include the ability to make (specified kinds of) statements.


What we want (User Model)
-------------------------

(1) When a statement is added to the policy, it overrides (replaces) any
contradictory earlier statements.

(2) The intention of a statement may be "...under *exactly* conditions
Y", specifying exact conditions, or "...under conditions Y, which is the
previous conditions modified in this particular way", specifying a
change in conditions.
(I'm somewhat unsure of whether we really need the "exact conditions"
ability. Really the only effect of that is to make it harder to
accidentally change permissions that shouldn't be changed.)

(3) When multiple contradictory statements are present in the policy, a
Human must decide which statement to believe. This resolution should
then become part of the policy, overriding the contradictory statements.

(3b) Requiring user intervention is annoying. When the policy contains
multiple statements on a topic, the system should attempt to find a
consistent interpretation before declaring them contradictory.

(4) Statements should not be affected by the addition of unrelated
statements.

(5) We don't want to believe arbitrary statements; a statement is only
allowed if both (a) some earlier statement says it is, and (b) the
current policy as a whole also says it is. (Or (c) it is one of the
Initial Statements, in the trust seed.)


How to get it
---------------

(1) requires that a statement carry a list of earlier statements on the
same (subject, action) pair. This can be used to build a DAG, which we
can run a merge algorithm on in the case of multiple heads to give (3)
and (3b). (2) can be handled by making statements have one of
{"conditions = Y", "conditions += Y", "conditions -= Y"}, and making the
merger sufficiently intelligent to understand these.

(5b) can be handled by running our normal find-trusted-heads procedure
on the statement DAG, with the trust for each statement determined by
the result of the (principal, ability to make the statement) statement
DAG. (5a) can be handled by only considering the portion of the
(principal, ability to make the statement) statement DAG which is known
to be earlier than the statement in question.

The procedure to satisfy (5b) can be self-referential. It should be run
after the procedure for (5a), and should only determine a statement to
be valid if neither its own validity nor invalidity would cause it to be
considered invalid (try both and AND the validity results).

(4) comes from simply considering each statement DAG independently.


Problem: how to handle template actions (ie, actions that contain more
than just a verb, like maybe a direct object)? Or, do we not need these?

Problem: what if there are several names for a user, maybe we allow to
use group names as the subject of statements? You would then have to
combine the DAGs for (user, whatever action) and (group, whatever
action) to be able to make decisions.

It would be useful here to re-read the SecPAL paper[0] that was linked
back in September. I don't think it can be used as-is for
self-describing rules, but it should still have many useful concepts.
[0] http://lambda-the-ultimate.org/node/1728


Implementation
--------------

Statement DAGs have a remarkable resemblance to per-file DAGs. Therefore
the appropriate history structure is to have the revision containing a
statement be descended from every earlier (ie, present at commit time)
revision containing a statement with the same (subject, action) pair.
Each (subject, action) pair has a filename, and the various conditions
can be represented by file attributes.

(Or should this be "descended from every earlier revision containing a
*valid* statement..."? This could have issues in the case of
multiple-statement revisions, where only some of the included statements
are valid. Being descended from an invalid statement shouldn't be a
problem, given that we don't consult the invalid statement when deciding
the value of the statement we're making.)

Revisions in the policy branch would not be trusted/distrusted as a
whole, but rather individual statements in the revision would be
trusted/distrusted. The only effect of putting multiple statements in a
revision would be to reduce cert bytecount overhead. (Well, and to make
it easier to specify initial policy in the trust seed. Starting with
multiple statements will likely remove the need to have an all-powerful
root user.)

I rather suspect that we would need a set merger (as opposed to the
scalar merger that is *-merge) to be able to fully provide (2). (Unless
we drop the "specify exact conditions" possibility, in which case
*-merge would work fine.)


Interface
---------

The trust branch should not have the same "checkout, use text editor,
commit" interface as a normal branch. Instead, the interface should be
"show the conditions for Bob to do X", "add/remove this from the
conditions for Bob to do X", "set the conditions for Bob to do X to Y",
"list pending changes", and "commit changes". These need to be
implemented as monotone commands to capture the intent mentioned in (2);
looking at text diffs can't give that information.

(ie, the trust branch needs a delta-oriented interface rather than a
state-oriented interface)


-- 
Timothy

Free (experimental) public monotone hosting: http://mtn-host.prjek.net