[cap-talk] keeping discussion on cap-talk - network capabilities, etc.

[Jed at Webstart]

All,

I just thought I'd take a crack at summarizing what I consider the
relevant points that have come up in this thread recently, while of
course expressing my own opinion:

Mark Miller wrote:

>...membranes (see 
><<http://www.cap-lore.com/CapTheory/Glossary.html>http://www.cap-lore.com/CapTheory/Glossary.html>) 
>are
>still possible even in such restricted object-cap systems, whereas they are
>not in cap-as-data or crypto-cap systems.

and Toby Murray replied:

>It might be due to a lack of experience in this field (only about 2
>years), or a personal lack of ability, however, I don't find the above
>references that helpful in deciphering the definiton of a "membrane".
>Could you  spell it out for me?
>Secondly, has it been proved that a cap-as-data system can't achieve
>this property? What is the reasoning behing your assertion?

I hadn't heard this term "membrane" before, but after reading the
reference I believe I understand what it refers to.  I believe what
it means (correct me if I get it wrong please Mark or others) is
a mechanism where a process can proxy a capability in such
a way that any capabilities that pass through to the holder
of the proxied capability are themselves proxied in an associated
way.  That is, the process doing the proxying can watch any
traffic coming in or going out on the proxied capabilities (e.g.
to further expand the membrane to any capabilities passed
out) and could do things like log any traffic or revoke all the
proxied capabilities en mass, etc.

Assuming I have this right, let me address the assertion that
such "membranes" are not possible "in cap-as-data or crypto-cap
systems."  I believe that either this statement is not true or perhaps
there is again some confusion about definitions.  In explaining my
reasoning I'd like to illustrate a point about what one might call
"mixed capability communication".

Let's take an example "membrane" (as above I assume) where
the capability being proxied is to a directory that contains an
entry "Joe" to some capability.  Our membrane implementation
finds itself in the position of seeing a "fetch Joe" request
coming through (whether it recognizes it as such or not).  It
fetches the "Joe" capability from the directory, saves it in
some table and creates a new proxied capability to send
on in the place of the returned "Joe" capability with the reply
from the directory server.

In a classical c-list (partitioned) system, the "Joe" capability
shows up in the c-list of our process implementing the membrane.
The membrane supporting process receives an index into
it's c-list for the "Joe" capability.  It creates a new proxied
capability and sends that on down.

What about in a "cap-as-data or crypto-cap system"?
In such a system the "Joe" capability arrives mixed in
with the data of the reply from the directory server.  If
I was understand Mark's "not possible" statement, I think
he was saying that such mixing would mean that the
capability would pass through unrecognized on down to
the process that invoked the proxy.

Of course if the capability was in the form of any
of the protected capability protocols described in
the Managing Domains paper:

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

including "access list", "encrypted address", or "public
key" (excluding only "password") or in the form of some
of the protected mechanisms that Toby referred to (XOR) -
I believe, then the resulting bits received by the invoking
process would be invalid as a capability (not grant access
to "Joe") - breaking the transparency of the 'membrane'
but not compromising any returned capabilities.

What I believe this illustrates is the necessity of understanding
the capability communication protocol by any process
utilizing and/or communicating capabilities.  The capability
coming down must show up in a recognized form in the
data coming from the directory server that allows the
membrane implementing process to process it properly,
save it, and proxy it in the message sent on down to
the invoking process.

One could worry that perhaps such a membrane implementing
process might not recognize such a communicated capability.
Suppose, for example, that part of the data returned from
the directory server, cleverly disguised as part of a reply
code or the like was:

<ssh://dns:home.webstart.com;user:jed;password:not-really>

I would call the above a "password" type capability.  An effectively
invalid capability to be sure, but it could be valid.

I want to note that such a 'capability' could as easily be
returned through the data reply from a directory server in
a classically partitioned c-list system.

To me the issue of how the receiving process is confined
(what rights it has to communicate) is independent of
these new capabilities being received.

I do believe binding rights to a resource with the right
to communicate to the server of that resource is a
useful mechanism.  It isn't something we did in our
NLTSS implementation:

http://www.webstart.com/jed/papers/Components/

(incidentally implemented before 1979 with "password"
type capabilities as per:

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

which was written in 1981 to describe some expanded
capability "protocols" that we were experimenting with
to provide greater protection for capabilities from
what I call "data theft" - for Toby's benefit.  I'm enjoying
reading some of the Montash capability papers in
so far as I can find them on the Web as work that
seemed to be comparable to in some ways but
unaware of our previous work)

but I appreciate the confinement value of doing so.
Such a confinement value can be achieved in
a "capabilities as data" system if the message
passing kernel can understand capabilities
just to the point of enabling communication.

Also, regarding when I (Jed) wrote:

>...consider
>the example of working with a dump (e.g. from a program crash).
>My program might be an editor run or a scientific simulation
>or ....  It faults and I decide to take it to some higher expert
>to deal with the problem.  I may know that the data in the
>dump is not sensitive.  However, what about any rights
>(e.g. capabilities) that the program has?  It may have rights
>to various files or even (heaven forbid) rights to my "home"
>directory."

and Toby replied

>Why can humans read out the caps in a memory dump but not a machine? is
>this not a data-mining/searching problem then to audit the process?
>Difficult but not impossible. Am I missing something here? (I suppose
>the program could obfuscate to prevent audit, but why would a system
>admin install such a program on a machine and why would a user trust it
>with their caps to their home directory etc.?)

Ben was following my thinking when he replied:

>I think the point here is that you have to grant access to the dump, and
>Jed is providing motivation for granting it.

If a machine had access to such a dump it could read it and could
read any such what I call "password" capabilities.  Even a consultant
that was given the dump and ran a debugger on it could pull out
such capabilities if they aren't protected from "data theft".  I was
just trying to justify mechanisms (as in the Managing Domains
paper, but unlike in Amoeba and the early NLTSS implementations)
that protect against such "data theft" despite the assumption that
generally a processes memory is safe from eavesdropping.

Finally, with regard to Toby's:

> > NOTE: this also means that any caps given to this process can't be
> > (usefully) passed on, since they won't be usable to any other process
> > (since keys are randomly generated by the system).  ...

and Ben's response:

>The argument I would use, then, is that the process doesn't, in this
>case, have the capabilities, it merely has keys to them. This is exactly
>how capabilities work in EROS.
>
>So, this isn't really a "caps-as-data" system.

I believe that the most useful way of using the term "capability" is as
anything that grants the right to use a resource.  The particular
form and associated mechanisms used for communicating capabilities
are part of the capability protocol - whether partitioned as in classical
c-list systems, tagged architectures, or more open ended capabilities
as data.

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.

I hope I'm not isolating myself on a terminological
limb.  If there isn't general agreement on this point
then it seems to me the whole notion of things like
"password" capabilities or capabilities as data, etc.
must be oxymorons to those who demand a more limited
definition of the term "capability."


--Jed http://www.webstart.com/jed/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.eros-os.org/pipermail/cap-talk/attachments/20041103/6c73ae5a/attachment.htm