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

[Marcus Brinkmann]

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.

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

Thanks,
Marcus