Re: Part 2: System Structure

[Bas Wijnen]

On Tue, May 23, 2006 at 10:46:34AM +0200, Tom Bachmann wrote:
> Bas Wijnen wrote:
> >> I'd like to encourage everyone to consider this. It sounds like a viable
> >> compromise
> > 
> > What exactly is "this"?
> > 
> 
> The proposal by jonathan:
> 
> >   There are opaque and translucent banks. The difference is that
> >   the opaque bank will not issue a given page more than once. A
> >   translucent bank will, which is how the user gains access to
> >   the content.
> > 
> >   An opaque bank can be a child of a translucent bank (or the
> >   other way around).
> > 
> >   There is a permission restriction on banks that prohibits formation
> >   of opaque sub-banks. If this bit is set, only translucent sub-banks
> >   can be allocated (this preserves recursive translucency).
> > 
> >   If an object is allocated from an opaque bank, it is marked (within
> >   the allocator) as opaque, and no parent bank will disclose it.

No, I do not think this is acceptable.  This means a program can protect
against the machine owner (or the user running a sub-Hurd) by creating
refusing to run on anything but an opaque bank.  You would need to write your
own implementation of the space bank (if that can be virtualized at all) to
get around this.  That is much too high a price to pay for being able to debug
a program which you own (that is, for which you have the binary image).

Protection for programs which are about to get capabilities which must not be
disclosed to the wrong parties is fine.  That is not what this is about.  This
is about protection from the user who owns everything that's known to the
program.  That must not be possible.  The user must be in complete control in
such a case.

In particular, that means that when starting a sub-Hurd on a transparent space
bank, it must not be possible that
- A part of the sub-Hurd becomes opaque
- A part of the sub-Hurd can see that it is running on a transparent (to the
  parent Hurd) space bank.

At least one of these conditions is not satisfied in the proposal (the user
may choose which, but can't choose to satisfy both without considerable
effort, namely hacking the space bank).

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