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

[Jonathan S. Shapiro]

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

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

shap