l4-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Marcus Brinkmann
Subject: Re: Challenge: Find potential use cases for non-trivial confinement
Date: Mon, 01 May 2006 06:53:56 +0200
User-agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (Sanjō) APEL/10.6 Emacs/21.4 (i486-pc-linux-gnu) MULE/5.0 (SAKAKI)

At Mon, 01 May 2006 00:33:33 -0400,
"Jonathan S. Shapiro" <address@hidden> wrote:
> On Mon, 2006-05-01 at 05:43 +0200, Marcus Brinkmann wrote:
> 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.

I'm surprised that this was not clear.  I said it in no uncertain
terms at the very beginning, when I explained what I understand by
"user autonomy" and "user freedom" (ie, the right to use, inspect,
alter and copy all resources attribute to/owned by the user).

> 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.
Yes, if you want to do that, you can do it.  If you want to be really
stupid, you can send nude pics of yourself over the web.  You can run
unconfined programs in EROS, too.  The point is that this is never
done by default, so you have to hit yourself over the head several
times to get there.  It will be harder to run such programs in my
system than it is to run unconfined constructors in EROS.

The default operation will be safe, in that it preserves confinement
as well as the user's freedom to use, inspect, copy and alter their
storage.  I have already explained why I think that this is important
to the free software movement and development.

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

Thanks,
Marcus





reply via email to

[Prev in Thread] Current Thread [Next in Thread]