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

[Jonathan S. Shapiro]

On Mon, 2006-05-01 at 07:17 +0200, Marcus Brinkmann wrote:
> At Mon, 01 May 2006 01:03:08 -0400,
> "Jonathan S. Shapiro" <address@hidden> wrote:
> > 
> > On Mon, 2006-05-01 at 06:53 +0200, Marcus Brinkmann wrote:
> > > At Mon, 01 May 2006 00:33:33 -0400,
> > > "Jonathan S. Shapiro" <address@hidden> wrote:
> > > > 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**.
> > > 
> > > The system will not, by default, run programs from foreign storage.
> > 
> > How did foreign storage get into this? I'm talking about two users
> > executing on the same system from the same hard disk. I do not
> > understand in what sense the storage is "foreign".
> 
> Ok, that was not clear.  The default libraries and services will make
> sure that the user does only execute programs from the user's own
> storage.

This STILL doesn't address my example. I started the program, and I
handed you a descriptor that allows you to send IPC to my program. The
entire point is that I have *not* permitted you to instantiate it
directly or control its storage -- even if we have a "naked" storage
allocator.

So the "naked allocator" restriction is not achieving the objective: the
user (in this case the recipient of the IPC capability) *still* cannot
examine the program they are executing.

So next we must remove IPC, or if we do not, we should admit that this
is an impossible objective and stop compromising the system architecture
in order to achieve it.

> 
> > > > 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.
> > > 
> > > FUD.
> > 
> > No. Truth. You just aren't thinking it through.
> 
> Well, you made the claim, you get to defend it, if you want.
> 
> But please note that in my model the recursive nature of the resource
> distribution means that no program has access to any storage used by
> its siblings or parents, unless explicitely authorized.

Yes. I understand. But this has absolutely nothing to do with what I
said. Think about it again after re-reading my example above until you
have actually understood the example scenario. I think that you must be
very tired. I have noticed that you are not reading carefully.

shap