Re: Challenge: Find potential use cases for non-trivial confinement

[Jonathan S. Shapiro]

On Mon, 2006-05-01 at 05:43 +0200, Marcus Brinkmann wrote:
> At Sun, 30 Apr 2006 23:13:49 -0400,
> "Jonathan S. Shapiro" <address@hidden> wrote:
> > 1. I create a new constructor, so I am the creator. I put stuff into the
> > constructor. I instantiate programs. So far this is all just "trivial
> > confinement" as you call it.
> 
> In my current system design, there is no constructor.  There is also
> no meta-constructor, and the space bank will happily let you inspect
> and alter the content of any memory that is taken from your reserve
> (well, the last point may or may not be true, but for the purposes of
> analysis, we can assume it to be true).

It follows immediately that the system administrator can inspect all
storage, since all space banks are ultimately derived from the primary
space bank, which is owned by the system administrator. So let us NOT
assume this about the storage allocator for a moment. I want to
establish that this assumption is actually essential in your proposal.

Suppose that the storage allocator does not allow inspection of my
reserve for page capabilities that I do not hold.

In this case, I can fabricate a process, hand it to you, not tell you
what it does, and you can use it (or not) as you wish.

I can also fabricate a constructor, not tell you what it does, and you
can instantiate copies of whatever it builds (or not) as you wish.

There is ABSOLUTELY NO DIFFERENCE from the perspective of either
disclosure or hiding. In the absence of such a difference, it is simply
stupid to discard the mechanism.


So we must now examine Marcus's *real* proposal, which is extremely
radical: Marcus proposes that ownership of storage should imply the
ability to read that storage. This proposal is consistent with the view
that "I should control how the information flows in my computer" (i.e.
in the storage that I own). It is consistent with the "no hidden bits"
goal.

But the really silly part is that this compromises the entire system
architecture to no purpose, because it fundamentally does not solve the
"no hidden bits" problem. I can still fabricate a process that runs
completely out of *my* storage and hand it to you. You can run it or
not, but you *still* can't know what it does. All that has actually been
accomplished here is to guarantee that if you *do* talk to this process,
you necessarily disclose information **to the creator of the process**.

Remember those dialog boxes that let you say "I never want to send
software registration information back to the vendor?" A naked storage
allocator is a lot like removing that choice for the user.


shap