[cap-talk] keys to capabilities? caps as data

[Jed at Webstart]

At 07:45 AM 11/4/2004, Sandro Magi wrote:
>Sandro Magi wrote:
>
>>Jed at Webstart wrote:
>>
>>>How then can I interpret the above statement that a process "doesn't ...
>>>have the capabilities, it merely has keys to them."?
>>>
>>>Does it have the right to access the resource?  If so
>>>then it has the "capability."  If not, then not.
>>
>>It has the capabilities, it simply does not have access TO the 
>>capabilities. In cap-as-data systems, the process has the capability and 
>>also has access to the capability. In cap-as-descriptors, it does not 
>>have the latter.
>>
>>In both systems, the process has the capabilities. At least, this is how 
>>I currently see it.
>
>Forgot to mention that this is why I think the XOR approach is not a 
>cap-as-data system. What the process holds is not the designator that 
>actually grants access to the resource. Since, the process does not have 
>access TO the actual capability, it is not a cap-as-data system.

I'm sorry, but that above sounds like double talk to me.  Somehow the
capitalizing of "TO" doesn't help my understanding.  Let me try to put what
I think you are saying in my own words and see if we can come to some
common understanding.

Are you saying that in a capability as descriptor system processes
don't have access to the representation of the capabilities that
are stored in a separate partition (e.g. c-list)?  If so, that much
is fine.

In a capabilities as data system, as I understand it, one of the main
values is that capabilities do not have to be partitioned separately
and can appear in the memory space of a process.  In such a case
it means that both the right (the "capability") and the representation
of the capability (= the right - just trying to clarify my terms) show
up in the processes memory space.  This approach makes many
mechanisms simpler (e.g. no separate buffering/flow control for
capability communication, etc.), but it also exposes the capability
representation to some threats, e.g. "data theft":

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

Perhaps I should mention that I am reading like crazy to catch up
on some of what are to me relatively recent developments in this
field of capability rights communication and access control.  For
example, I just read much of:

Capability-Based Protection in a Persistent Global Virtual Memory System
by Jerry Vochteloo, et. al., 1993:

http://citeseer.ist.psu.edu/261535.html

If that "XOR" system is the one referred to with respect to above,
then I think I must have confused it with something else.  That scheme
is only used for converting one capability to another with lesser
rights without communicating to the server by use of a one
way function.  It doesn't provide any protection from data theft.
To protect from data theft there must be some transformation
that a process does to a capability in it's memory space before
communicating it to another process, e.g. as with the sending
and receiving operations outlined in:

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

I don't really understand the attitude of those who support
capabilities as data to what I consider to be the 'problem'
of data theft.  I notice that Andrew Tannenbaum (Amoeba)
said in one of his most recent Amoeba papers:

"...if the system (Amoeba) were to be extended to millions of machines 
worldwide, the idea
of using capabilities would have to be revisited. The fear is that casual 
users might be
too lax about protecting their capabilities. On the other hand, they might 
come to regard
them like the codes they use to access automatic bank teller machines, and 
take good
care of them. We do not really know."

from: "THE AMOEBA DISTRIBUTED OPERATING SYSTEM—A STATUS REPORT"

I think this aspect of capabilities as passwords, showing up in program
memories in a form useable to anybody who sees the date in the memory,
doesn't constitute taking "good care of them" (capabilities).  I certainly
wouldn't consider doing such a thing with a right to my automatic
teller machine (combination of card and pin).

To me this is a problem the capabilities as data people haven't really faced
up to.  I architected a number of ways to get around this problem in:

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

as a way to protect NLTSS/LINCS from such criticism.  We never
successfully implemented such protection as the costs (including
programming costs) seemed too high at the time.

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