[cap-talk] Paradigm Regained: Abstraction Mechanisms for Access Control

[David Wagner]

In article <5.2.1.1.2.20030822212628.028b8fe0@caplet.com> you write:
>At http://srl.cs.jhu.edu/pubs/SRL2003-03.pdf you will find the paper Shap 
>and I just submitted for my invited talk at 
>Asian'03 http://www.cse.psu.edu/asian03/ . We expect to hear back from 
>referees on Sep 7, so we have one more round of revision to go before camera 
>ready. Discussion would be most enjoyable and quite valuable. Thanks.

Below are some comments I sent to Mark in private email.  He suggested
I send them here, to encourage discussion.

Disclaimer for onlookers: I try to be as brutal as I can when commenting
on papers, sometimes playing Devil's advocate, and without spending
too much effort on being extra tactful or polite, because that's how
I like people to comment on my own drafts.  Everything is intended
as constructive criticism, so please don't take this the wrong way.
I quite liked the paper.

-- David

I liked the paper, and the point of the paper.  It is nice how you
show how abstraction boundaries can help with the composition problem
in security.

How does this relate to Clark-Wilson?  Your work seems to have a very
strong intellectual affinity to the Clark-Wilson model.  Maybe one way
to phrase the main point of the ASIAN paper is that capabilities give
one nice way to create lots of Clark-Wilson-style security perimeters.

I found it a little hard to extract what the main thesis of the paper was.
I wish the paper had tried to summarize the key point of your argument
in a single thesis statement.  Suppose your readers are only going to
walk away remembering just one lesson from the paper; what would you
want that conclusion to be?

Other than the above, I have only very minor comments:

A small reaction to word-choice.  This is at least as subjective as one's
favorite color, or some such, so treat this accordingly, but here's my
view anyway.  I have a certain hesitation about using the word "authority"
in the way the paper draft currently does.  The aspect I dislike is when
the draft uses "authority" to draw a distinction with "permissions".
I'm not fond of using "authority" to represent what Bob _happens_ to be
able to do -- as opposed to what Bob has explicitly been authorized to do
(what he _should_ be able to do).  It's the difference between actual
behavior (of the access control system) vs desired behavior.  The word
"authorization" has a long tradition in the computer security community of
referring to what policy we intend our system to enforce, rather than its
actual behavior.  In other words, "authority" has conventionally been for
prescriptive rather than descriptive purposes.  In this sense, using the
word "authority" to refer pointedly to descriptive behavior strikes me
as flying in the face of tradition, a little bit.  The risk is that the
draft's usage might cause confusion among some readers who are more used
to the traditional usage.  (If you agree with this analysis, how about
substituting some other word, like "powers", instead of "authorities",
when referring to the actual things that Bob can do?)  On the other hand,
p.2 is quite explicit about what you mean by "authority", so maybe things
are ok.

In Section 3, 2nd and 3rd to last sentences: I spent a long time trying
to decide whether maybe you should have meant "least permission needed"
and "only these permissions", rather than "least authority needed" and
"only these authorities".  On the one hand, the caller of cat can only
control the permissions given to cat, but may not be able to do much
about other authorities cat may have.  On the other hand, it is the
authorities that we really wish we could limit.

Section 4, 2nd and 3rd paragraph: I was trying to figure out exactly
what counts as an object-capability system.  For instance, is it
true that any type-safe OO language is an object-capability language?
Maybe this gets into some irrelevant tangent that would only distract
from your main point, but if it is true that all type-safe OO languages
are object-capability languages (or somesuch thing like this), it might
help the intuition of the reader to explicitly state this.

Section 4.3: I thought it would have been clearer if you first gave a
worked example of a filtering facet (with more detail), and only then
after that gave the example of the Caretaker pattern.