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.)
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