[cap-talk] Wikipedia: Object-capability model - excluding distributed

[Jed Donnelley]

At 03:36 PM 1/11/2007, Mark Miller wrote:
>On 1/11/07, Jed Donnelley <capability at webstart.com> wrote:
> > Let's consider an example of a process environment where
> > the only "system call" is an invocation of a YURL.  However,
> > let's further suppose that only YURLs that have been signed
> > by the local component of the capability system (think of
> > a vat if you like) can be invoked and that the local component
> > of the capability system signs such capabilities (YURLs)
> > as they arrive through invocations of other signed YURLs.
> >
> > Would you consider the environment seen by a process
> > operating under that regime an "object-capability" system?
>
>Clearly not. Take the *-property example in my Section 11.2. Let's say
>that Cassie, Q, Bond, and all facets of the data diode are all on
>machine A, and therefore within the scope of one "local component of
>the capability system", i.e., one signing key. Q can now realize
>Boebert's attack, and send a properly signed YURL to himself
>seganographically through the data diode to Bond. Bond can then invoke
>it to talk to Q. By contrast, the Monash system is not vulnerable to
>this attack.

Hmmm.  I'm not sure if I'm misunderstanding your attack or you
are misunderstanding my example.

When I indicated above that the YURLs had to be signed by
the local component of the capability system, what I had in
mind was what I've described before where each domain
(active object) has a distinct key that isn't available to the
active object itself.  That is, the signing of a 'capability' (object
reference) happens outside the control of the "process" when
such a reference arrives through an invocation.  Data received
must be processed by this component of the "TCB" before
any capabilities can be used to invoke or to delegate (where
similar processing happens on the sending side).  Remember,
I'm just making this up.  No such system exists that I know of.
I'm doing such a design (as I did with the two vat system)
just to try to get at the essential characteristics of the
"object-capability" term.

Can you explain to me how with such a mechanism Q can
"send a properly signed YURL to himself seganographically
through the data diode to Bond?"  In the sort of system
I described, while capabilities are data, it's cryptographically
impossible to "introduce" a capability as data (i.e. to get
the signature on it needed for invocation) - e.g. by reading
something from a file or typing something in.

I'm also a bit lost with what I assume is a reference to
stenography.  How is that relevant?

I believe this example is also addressing AlanK's concern:
"An important feature of object capabilities is that 'only
connectivity begets connectivity'".  If so perhaps we can
combine these threads?  If not then perhaps somebody
can explain the distinction?

I hope we're all working on this together in an effort to
resolve just what any essential differences might be
that separate component systems from distributed
systems.  In doing so it seems we're dealing with the
keeper of the object-capability term - namely you MarkM.
As I understand it, you agreed that the DCCS with no
encryption and pure object-capability systems at the
ends of the network qualifies as an "object-capability"
system.

What I'm trying to do is to work out from that example
by successive "refinement" to discover where the essential
difference comes in between such an object-capability system
and other systems such as cryptographically enforced
systems (e.g. like this example where it's the TCB of a
local capability component that does the encryption).
Is it 'just' the business of theory vs. engineering (guessing
large random numbers) or is there something more fundamental
involved - like "only connectivity begets connectivity"?

>Note that I have never disputed the claim that the *-properties are
>useless in practice. But this example demonstrates that they are a
>great scalpel for distinguishing different kinds of systems. In
>particular, this example demonstrates that purely cryptocap (or sparse
>cap systems) like Amoeba are fundamentally weaker than Monash or
>objcap systems.

I hope to better understand in what way "purely" (not sure if what
I describe above qualifies) cryptocap or sparse cap systems are
fundamentally weaker than Monash or objcap (still a bit of a
fuzzy term to me) systems.  I'll keep working at it, though I
expect 30 seconds at a white board would suffice to come to
a resolution.  I guess there are some advantages to a discussion
like this in a public forum.

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