[cap-talk] capabilities Q, Alan Karp & David Wagner

[Jed at Webstart]

At 07:12 PM 6/18/2006, Karp, Alan H wrote:
>Jed wrote:
> >
> > Right, but remember what the basic point is that we're trying to get
> > at (if I have this right), namely the added value that comes from
> > using a POLA (e.g. almost necessarily "capability") approach to
> > authorization rather than "ambient authority" (users, groups, etc.).
> >
>And there's the disconnect.  I use the Solitaire example in my Polaris
>talk.  Polaris uses ACLs, userids, groups, and all that junk.  I'm just
>getting the audience to recognize that the fundamental problem is that
>we give all our authority to every program we run.
>_________________________
>Alan Karp

Good.  Got it.  I think that David Wagner's presentation was more directly
focusing on capabilities.  For that presentation (that I, and perhaps others
may steal from in the future) I believe some of my suggestions pointing
out problems with "ambient authority" models (programs dealing with
authorities in terms of "users" - directly and as deputies) vs. the capability
model are relevant, in fact vital - the main point.

David W.'s interests seem to focus on language implementations of
capabilities.  For a presentation with that focus I think the later part
of his presentation, particularly is appropriate.  For a general discussion
of:

"Object Capabilities for Security"

(the title of his presentation), however, I believe one must directly face
the question of:

"Object Capabilities" vs. what?

That is, what are the alternatives to using object capabilities, and how
does using object capabilities compare with the alternatives?  I believe
really the only alternative is what we refer to as the "ambient authority"
model.  Namely the model in which programs run as "user"s.  There
are a variety of means for adjusting authorities of users within such a
model (e.g. file access bits, ACLs, etc.), but they all come down to
essentially the same thing, namely programs running as users and
trying to manipulate authorities in that context.

Even the people who continue to cling to the bogus notion that
capabilities are rows and ACLs are columns representing the
same thing (completely ignoring the dynamics of the situation
and the capabilities deal with domains on a process or thread
basis vs. the human user with the ACL or user/group/other
read/write/execute approaches - as noted in the Capability Myths
Demolished paper) need to be confronted with the value
capabilities bring to the table vs. the ambient authority model
which includes ACLs (except when implementing capabilities as:
http://www.webstart.com/jed/papers/Managing-Domains/#s10 ).

I believe it's important for us on this list (at least) to have quite a clear
picture of what the trade-offs are between these two models, regardless
of whether we are considering the contrasts at the language, the
OS (e.g. classical c-lists), or the network (e.g. YURLs, capabilities
as data) levels.

I believe David's presentation is a useful contribution to clarifying
these tradeoffs.  I guess I was just trying to make suggestions that
would "tune" it to deal with this most general context of a comparison
between object capabilities and the alternative.

--Jed http://www.webstart.com/jed/