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

[Jed Donnelley]

At 01:29 PM 1/8/2007, Mark Miller wrote:
>On 1/8/07, Jed Donnelley <capability at webstart.com> wrote:
><snip>
>
>Now that I understand the mutual reliance assumptions behind DCCS, if
>we additionally consider the DCCS remoting system to be part of the
>shared reliance set (platform, TCB, central point of failure), then I
>would classify the actual DCCS system as an objcap system. From a
>security perspective, a DCCS "network" isn't distributed. It's a
>single multiprocessor CCS computer spread out over space by using a
>very long backplane. Within this system, a CCS domain cannot break the
>objcap rules even if it is an unfeasibly lucky guesser.

Ah.  Then in that case I guess you will (if you get time) respond that the
vat-vat dual system over a shared hardware link mechanism that I
described in:

http://www.eros-os.org/pipermail/cap-talk/2007-January/007005.html

will also be considered an object-capability system with, as you
suggest, a very long backplane (serial to be sure).

I expect then (but I'll have to wait to hear from you to be sure)
that you will also accept that such a system meets your
confinement requirements, 11.5.1 (MarkM thesis reference),
and your *-property requirements, 11.5.2.

Do you also accept that such a distributed mechanism suffices
in the reliability area regarding issues like a network partition (11.5.3)?
Perhaps you can look at my discussion of the tradeoffs between
local reliability issues and those across such a link and see what
you make of that.

>Curiously, but for the absence of crypto, DCCS contains all the logic
>needed for a true distributed cryptocap system (drum roll) among
>mutually defensive machines on open networks with no central points of
>failure. (Is there any short way of stating that condition? Perhaps an
>acronym? AMDMOONWNCPOF? Nah.)

As with the dual vat system that I described in:

http://www.eros-os.org/pipermail/cap-talk/2007-January/007005.html

the DCCS needed no cryptographic means because it assumed that
it could depend on it's network to properly identify communicators
by hardware means.  We had such networks in those days...

If all that above works (a bit to swallow, I'll look for your reaction), then
it seems that for implementations of distributed capabilities based
on cryptography the issue blocking them from being considered
"object-capability" systems is the information guessing concern.
That is, as you say of the Monash system, it's protection system
"is knowledge limited rather than permission limited."

Everything else, confinement, *-property, revocation, etc.  All
the functionality of any of the highest and best "object-capability"
systems can be met by a distributed system using cryptographic
means to implement assurance of it's cross machine protection
mechanism - except that in principle some system could guess
some secrets that are consider infeasible to guess and thereby
break the integrity of the system.

Personally I consider this a nit.  If you look at the implementations
of the hardware for many large single memory image computer
systems I expect you'll find the potential for statistical failures.
E.g. consider SECDEC memory as an example.  Memory failures
happen.  How frequent are they relative to cryptographic failures?
I don't know, but the fact that we can ask the question suggests
to me that the comparison is quantitative rather than qualitative.
A similar comparison is brought up in the Walnut system discussion
where they say (I summarize), what's the point of worrying about
guessing capabilities as data if entry to a system is done on an
open network with a username/password pair that's easier to guess?

This reminds me again of my extraterrestrial example, but I'll
forego that one this time...

 From my perspective the criteria for being an "object-capability"
system should be functional, not based on some theoretical
grounds of being able to break an encryption scheme by
infeasible guessing.

I'll be interested to hear how others feel about this.

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