[cap-talk] Abstractions that subsume capabilities (was: Re: What sparked interest in capabilities)

[Jed Donnelley]

On 3/6/2008 10:32 AM, Raoul Duke wrote:
>>   2. They are a beautiful abstraction about security, and I like
>>   beautiful abstractions.
> 
> Moi aussi. Are there abstractions which subsume capabilities?

Interesting question.  I would say that there are, though I don't
know of any that are popular enough to have a common terminology
to refer to.  I'll leave that thought for others to dispute.

We do certainly discuss what constitutes "capabilities" on this
list enough that I think one can consider the broadest definitions
to subsume our most common usage.  For example, consider the
definition of a "capability" that I give in my 1981 Managing
Domains paper:

http://www.webstart.com/jed/papers/Managing-Domains/
_________
For our discussion it will be convenient to have a single term to
denote resource access. We will use the term capability [DeV66-3,
Eng72-10, Fab74-11, Lan75-17, LaS76-18, Wul74-28]. We say that a
process has a capability to a resource if it has been authorized
access to the resource. A capability is thus a key that can unlock
access to a resource. We define the domain of a process to be the
set of capabilities that it possesses.

This use of the term capability is a generalization of the way it
is often used in the discussion of capability-list (C-list) OS's
[Lan75-17, LaS76-18, Wul74-28]. In C-list systems, capabilities do
authorize resource access, but the term is generally restricted to
refer to a specific form of capability implemented as some type of
pointer that is protected by the kernel of a stand-alone OS. In
such systems all communication and validation of capabilities (in
this restricted sense) is mediated by the system kernel. This
centralized approach to access control unfortunately does not extend
well into a distributed environment [Don76-5, Don79-6].

Our purpose here is to explore the types of protocols suitable for
capability passing and validation in a network OS. Our protocols
must allow serving processes to give out capabilities to potential
users in such a way that:

    1. The capabilities can be validated when used as authorization
       for service requests.
    2. The capabilities can be communicated or passed between any
       two processes that can communicate data.
________

where I referred to this diagram:

http://www.webstart.com/jed/papers/Managing-Domains/Figure-3-50.gif

Incidentally, are there earlier instances of that essentially
"Granovetter" diagram in publications about capabilities?  It's
a rather obvious concept and of course the capability paradigm
had been discussed for at least 15 years by that time, but I'm
not aware of any earlier such diagrams.  One can easily see
why I needed it for that paper.

That definition is general enough to include what I describe
as an access control list mechanism for implementing "capabilities"
as well as an "encrypted address" mechanism that is a variation,
both based on a validated "from" address with received data
(e.g. based either on the physical network or on cryptography).

To me its easier to understand the essence of what has more
recently been called the Communicating Conspirators problem
which there I referred to in a more positive sense as what
I called the "Inalienable Right to Pass Capabilities"
(Pass = Communicate in that context).

I believe that what I refer to in the Managing Domains paper
as the "Reflection Problem" provides a convenient test for
'Confused Deputy' problems in the context of generalized
"capabilities".  The basic idea there is that if a domain
can exercise a mechanism for communicating access
(communication of a generalized capability) in such a
was as to fool the receiver into believing that it received
more than the sender had, then there is a problem in the
mechanism.  The 'test' aspect that ties into the 'reflection'
notion is that one can tell if such a problem exists by
"sending" a capability from A to B and then back to A.
If A ends up with more authority than it had to begin with
(e.g. something inherited from B's greater access) then
there is a problem.


I personally don't see any greater generalization between
the above sort of broad "capability" concept and the most
generalized access control context for resource access.
I believe that all the more general access control paradigm
contributes in terms of flexibility is allowing the setting
of access rights by mechanisms other than what amount to
messages.  That is, there are mechanisms where access can
be granted when communication isn't possible (e.g. as with
the dominant Unix/Windows access control mechanisms that also
includes the notion of "owner").

Hmmm.  I spent a bit of time looking around on the Web and
didn't find anything that I would consider a 'taxonomy' for
access control schemes.  The Wikipedia page on "Access Control"
divides such mechanisms into:

Discretionary Access Control (DAC), Mandatory Access Control (MAC),
and Role Based Access Control (RBAC).

I consider the above a pretty horrific categorization.  Whew.
Has there been any sort of a review of this general topic
since Saltzer and Schroeder's "The Protection of Information
in Computer Systems" from 1975?  That paper divides access control
mechanisms into "capability" and "access control list" mechanisms.
It seems that the Wikipedia categorization lumps the capability
category under DAC with other user managed access control list
mechanisms - though capability mechanisms may be so little
considered as to be essentially ignored in discussing modern
access control mechanisms.

My ignorance of any such general references may simply reflect my
being out of the field for so long.  Or, it might reflect that lack
of any substantive work in this area over many years (the reason
I got out of the field).  In either case I'm quite interested to
see any references that people might feel are relevant.  If we can't
find any relevant references, that would seem to me to suggest a
possible opportunity to define the field in a way closer to our
interests...

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