Thoughts on droplets

Mark S. Miller markm@caplet.com
Tue, 02 Nov 1999 11:31:15 -0800


At 05:36 PM 11/1/99 , shapj@us.ibm.com wrote:
>As promised, here is the "more later."  I'm taking various bits as separate
>topics.
>
> > My falsifiable claim: any inter-machine
> > "partitioning" protocol does not enhance
> > any actual security.  These kinds of
> > unpartitionable data-capabilities implement
> > the most capability security that can be
> > implemented in the distributed context.
> > Machines cannot be confined.
>
>I believe that this argument is false.  There is a level of abstraction at
>which it is true, but there is a fallacy embedded within it.
>
>Consider a non-distributed capability system such as EROS.  To most of the
>software on the machine, capabilities are opaque.  To the kernel, they are
>directly manipulatable and their representation as bits is manifest.  This
>is okay because the kernel is trusted software.
>
>To implement a distributed, user-opaque version of this system, we need:
>
>1. A mechanism for suitably encrypted communication between the two kernels
>over the otherwise open network.  This is straightforward; the problem is
>merely where the keys should be stored.
>2. A mechanism for secure bootstrap of those kernels.
>3. A mechanism by which one machine may verify that the other's kernel is
>trusted.
>
>The last two problems can be solved by use of a number of hardware add-in
>cards.
>
>Therefore, I believe that MarkM's claim is flawed.  The flaw lies in the
>presuption that no software can be trusted, and that if it could there is
>no means to assure that the software is running on real hardware.

I am making that presumption, and I agree with Tyler's explanation of why
it's the only practical assumption.  However, you aren't necessarily arguing
practicality, all I know you to be claiming is a falsification of my claim
that

> > These kinds of
> > unpartitionable data-capabilities implement
> > the most capability security that can be
> > implemented in the distributed context.
> > Machines cannot be confined.

An impractical alternative that demonstrates more security would indeed
falsify this claim, so we can set aside the practicality issue for now.
Let's examine your alternative.

First of all, since your "A mechanism by which one machine may verify that
the other's kernel is trusted" isn't very specific -- trusted by whom? --
I'll go ahead and use the model of Opaque Boxes that Drexler & I explain at
http://www.agorics.com/agoricsPapers/aos/AOS6.html#section6.1.2 .I believe
it is sufficient to do what you intend: to create a single shared TCB spread
over multiple machines.  (If this is not equivalent to what you have in
mind, please clarify.)  This definitely does enable different security
patterns, since, as with an operating system, there is now one common
platform (with a distributed implementation) that all parties can be assumed
to trust.

There are now two possibilities to consider for the inter-machine capability
communications system: either the comm system is considered part of the
shared TCB and therefore all instances of the comm system trust each other,
or it is unprivileged and the instances are mutually suspicious.  (There may
be a reason to consider intermediate scenarios, but I know of none.)

* If the comm system is unprivileged, and each machine-local instance of the
comm system is suspicious of every other comm system it is talking to, then
we end up needing the full logic of (the simplified version of) Pluribus --
VatIDs and swiss numbers.  The comm system identity becomes the equivalent
of the vat identity.

* If the comm system is part of the shared TCB and therefore mutually
trusting, which I believe is the case you have in mind, then not only do we
not benefit from adding any partition-supporting transformations to
Pluribus, we no longer need most of Pluribus.  We don't need VatIDs since
there is no vat-impostor problem.  We merely have to authenticate that we
are talking to another trusted opaque box, and set up a secure SSL-like data
pipe.  We also don't need the unguessability of swiss numbers.  Instead, any
system for cooperatively assigning unique numbers can be used, such as
tumblers (though I'm not recommending it) since only our shared TCB will be
assigning or using these numbers.  These numbers indeed like the
representation of capabilities in an OS kernel that you mention above.

 From private conversations, I know you believe that, in the OS case, support
for partitioning (which you still need to explain to the list) is best
done outside the kernel, and that there is no security to be gained from
doing it in the kernel.  I claim the same is true of the inter-machine
protocol, whether or not we are making a shared-TCB assumption.

So to falsify my claim, it seems we still need an explanation of how a
different protocol (partition-supporting, session vs global transforms, or
whatever) can provide further capability security properties in either the
shared or separate TCB scenarios.


         Cheers,
         --MarkM