[cap-talk] the prize - scope and mechanisms

[Jed Donnelley]

At 08:23 AM 10/21/2004, Karp, Alan H wrote:
>Charles Landau wrote:
> >
> > I think you're attempting to broaden the scope of the discussion
> > beyond what was intended. We are discussing mathematical models of
> > security mechanisms that have application to computers. In a
> > mathematical model, one can limit risk to exactly zero, and that's
> > what we should aim for.

While I agree that it is possible to limit risk to exactly zero in
mathematical and computer models, and while I also believe that we
should aim for zero risk, I believe that making risk effectively
"as small as need be" suffices for practical purposes.

I think the example of encryption is both illustrative and practically
important in this context.

If the issue is protecting data traveling across a communication
channel from eves dropping (unauthorized reading) then one
approach is to keep the channel physically protected (e.g. within
a single computer keeping it unavailable for unauthorized reading
or in the context of a network keeping the physical channel
protected - e.g. by electrical shielding, etc.).  Another approach
is to use cryptographic means to protect the data while on the
channel.  The risk then of unauthorized reading is not truly
zero (we all know of many examples of broken cryptographic
systems), but it can, in my opinion, be made "as small as need
be" by using a cryptographic system that is strong enough for
the practical needs.

However, I believe this noted below is addressing an entirely
different issue:

>I don't see how the risk can be zero.  If Alice gives Bob a capability,
>there is always a chance that Bob will abuse that capability in some
>way.  There is also the possibility that Carol will abuse the capability
>by subverting Bob's machine.  These are among the risks that Alice must
>be willing to accept to gain the benefit of giving Bob the capability.

I think it important for any discussion to distinguish between:

1.  The issue of designing, implementing, and supporting an effective
(including secure) rights communication mechanism

and

2.  The use that process make of that available mechanism.

If Alice has an effective rights communication mechanism available
for sending the right to the Carol object to Bob, then Alice can
effect that communication without being concerned that others
might inappropriately receive the communicated right, that the
right might not be fully or wholly communicated, etc.

However, the idea of the rights communication mechanism is
exactly that Alice be able to send the right to the object serviced
by Carol to Bob and that after doing so Bob is able to exercise that
right.  All we can ask of our rights communication mechanism is
that it effects this rights transfer safely with 100% accuracy.
We can ask nothing about restricting Bob's ability to exercise
the right for good or ill after it is received.

I believe that too often in the design of rights communication mechanisms
a concern about what a process will do with a right once it has been received
have ended up clouding the rights communication designs.

I'd like to illustrate with two examples (somewhat related as we will see),
one that I consider legitimate (right revocation) and one that I consider
illegitimate and ultimately counterproductive (can't share):

A.  Right revocation.  This is the desire on the part of Alice to be
able to at some time in the future decide to invalidate the Carol
right that Alice sent to Bob.  It is understood that Bob may
have made any legitimate use of the Carol right between the time
it was sent from Alice until the time of the revocation, but that after
the revocation the right will no longer function.

I see this revocation notion as somewhat related to our proxying
discussion and the idea that an object is defined by its behavior.

If an object can be proxied (e.g. it is defined by its behavior - though
perhaps less is required) then of course that is one means to achieve
this desire for revocation.  Alice can create a proxy right (capability),
send that to Bob in place of the original Alice right (capability) and then
at a later time invalidate the proxy - either by Alice herself or through
whatever proxy mechanism that was used.

I believe that such a revocation facility is basic enough and is so
easy to provide by the base object server that it should be provided
by base object servers rather than forcing users of the resource to
resort to proxying to achieve revocation.  In the base server it is as
simple as redirecting through a table of unique identifiers and providing
the ability to remove a formerly supported identifier in the table.  While
proxying isn't too difficult either (providing the underlying resource
sharing model is well behaved - see "network discipline" and the
"insertion property"), it does introduce what seems to me to be
an unnecessary layer of inefficiency that can be avoided with
effective server design.

B.  Can't share.  This is the desire on the part of Alice to be
able to make it impossible for Bob to share the Carol resource
that Alice sent to Bob with some other process that Bob is able
to communicate with.  This sort of effort at limiting rights communication
showed up at least in Demos:

Baskett, F,, J. H. Howard, and J. T. Montague, "Task Communication in Demos,"
in Proc. of the Sixth Symposium on Operating System Principles, Purdue 
University,
November 16-18, 1977 (in ACM Operating Systems Review 11(5), 1977), pp. 23-31.

and I believe (but don't right now remember which) in some other systems.
In Demos it showed up as a "can't share" or "pass once" bit in the "port"
(essentially the Demos capability) that was communicated.  The idea
was the by setting this bit in the right communicated from Alice to
Bob it would keep Bob from being able to further communicate it to
others that Bob is able to communicate with.

I believe such a notion is ineffective and ultimately counter productive.
I've written about this in:

http://www.webstart.com/jed/papers/Managing-Domains/#s6

The basic idea is that if a right can be shared anyway by
proxying it (which it can if the processes can communicate)
then why force such awkward mechanisms for sharing when
a simple mechanism will do.  If Alice doesn't quite trust Bob
and wants the ability to revoke a shared resource, use the
revocation mechanism.  It won't stop initial access, even by
some other process that Bob might communicate with, but
it can cut off future access at any time.

I refer to the ineffectiveness of such efforts at rights communication
as "The Inalienable Right to Pass Capabilities" (or rights if you prefer).

To summarize, I believe the scope of our rights communication
(capabilities) discussions should be on the underlying mechanisms
for the rights communication itself (e.g. with things like revocation
and the right to communicate received rights) and not on how such
a mechanism might be inappropriately used - e.g. by Alice sending
a right to an untrustworthy Bob (unless of course something about
the base underlying mechanism makes such inappropriate sharing
more likely).

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