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

[Bas Wijnen]

On Mon, May 01, 2006 at 12:33:33AM -0400, Jonathan S. Shapiro 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.

This is getting annoying.  I wrote at least twice already that the primary
space bank is *not* owned by the system administrator.  It is owned by the
TCB, which is an entity itself.  It will restrict access to it carefully, in
particular it will not give anyone (and that includes the administrator)
direct access to the prime space bank.

The user session manager is also part of the TCB, and it will also refuse to
give full access to its (sub)spacebank.  That means that when the user asks
its session to create a new subspacebank, it can indeed be sure that noone is
watching, because it is not possible to set up a "watcher" before the
subspacebank was created.

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

It is no problem if it is.

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

In fact, if a mechanism cannot do anything that can't be done without it
(doing something faster counts as something in this case), then there is no
reason to keep it.  You say there needs to be a reason to discard things.  I
disagree.  There needs to be a reason to keep things.

I am very conservative, in a way.  I am usually against radical changes.  But
this is because there is a reason for the things being the way they are, and
this reason is often still valid.  Conserving things just because there's no
reason to discard them is wrong.

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

If you have a case where this is actually a practical problem, please submit
it to Marcus' challenge.  We already know that the constructor can do things
that are impossible without it.  The statement is that none of these things is
worth supporting (for the Hurd).

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

Let's be realistic.  The user doesn't care much.  Suppose I am a spam king.
If there is a constructor and I don't use it, and I give a random user a
program which he can run off his own storage and which will report back to me,
hardly anyone will complain.  I, being a spam king, will ignore those
complaints and get lots of information about lots of people.

So what's the difference?  Without a constructor, it will cost you resources
to be evil.  (There're some extra steps and analogies before this conclusion
can be drawn, but I hope you see it.)  That doesn't sound bad.

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://129.125.47.90/e-mail.html

signature.asc
Description: Digital signature