Re: Restricted storage

[Bas Wijnen]

On Mon, May 29, 2006 at 06:28:02PM +0200, Pierre THIERRY wrote:
> > Theoretically I agree, but I don't see much use for anything other
> > than "opaque", "readable data", and "unrestricted".  Anything other
> > than "unrestricted" (to the user, I'm fine with "opaque" to the
> > requestor) is very special.
> 
> Then you break the Flexibility requirement. I don't see a valid reason
> to do so. If you want to break a requirement, you have to point out a
> strong need for it.

I did, but you cut it away:
> > I don't think it's useful to build a whole system of sub-permissions on
> > it, because it will only result in accidental disclosure of certain parts
> > (because the default is unrestricted.  Making the default opaque would
> > solve this, but at a much too high cost IMO).

> > > > - When a user starts a sub-Hurd (or debugs a program in some other
> > > > way), it must be impossible for the program, or any of the
> > > > programs it spawns on its own storage, to become restricted.
> > > Then again, this breaks Flexibility. This also breaks
> > > virtualization. I don't see why a sub-Hurd could not be a "real"
> > > Hurd, with all the possible features of Hurd.
> > It is.  And it behaves exactly the same.
> 
> Then please describe the properties of your system more carefully. You
> didn't specify for which process the child in the sub-Hurd could not be
> restricted any more.

Right, sorry.  This was for the process spawning it on transparent storage,
not for its siblings within the sub-Hurd.

> > If P owns C1, then C1 automatically trusts P completely.
> 
> Then why would you need anything else than translucent storage?! You're
> making an assumption here that makes the whole discussion obsolete...

This is not an assumption, it's a statement.  "P owns C1", for clarity, means
that P has proved C1 with all its capabilities (including the space bank), and
with its initial code image.  P spawns C1 for a reason known to itself.  C1
will do exactly what P wants it to do, or else there's a bug in it.  There is
no way that C1 can try to "defend" against P, because P is its sole reason for
existing.  If C1 would want to defend, P can just change the code image so
that it doesn't.  There is no possible successful defense against P, so it is
meaningless to suppose that C1 might want to try.

> > > But I think this makes the constructor unavoidable if you want
> > > restricted storage to be of any use, because the check that the
> > > storage is indeed restricted has to be made somewhere.
> > If you want to start a process in restricted storage, it must be
> > started by a service which checks that the storage is restricted.  It
> > doesn't have to be a constructor
> 
> Maybe it won't be a constructor exactly, but I think it will have many
> properties of the constructor.

Yes.  It may be reasonable to call it a constructor, but that would confuse it
with Jonathan's constructor, which is much better defined.

> > > How is your restricted storage non-recursive?
> > If C1 creates an opaque sub-space bank from its own (to run C2 on),
> > then it doesn't become recursively opaque to C1's parents.
> 
> Then your proposal is absolutely of no use in the competition and ping
> cases, IIUC.

What they need is opaque storage and a means for the process spawning service
(constructor or not) to verify the opaqueness.  This is possible if the opaque
storage that they accept must be a direct sub-space bank of the user's session
bank, because then they can ask the session (which they can trust, too,
because it's part of the TCB) if this is really opaque storage.  Why do you
think this would not work?

What it does make impossible is programs hiding data without the user's
permission (in the form of a capability to the opaque storage generator).  In
Jonathan's model, they can do that.  It's one of the big selling-points of
my model that they can't, in fact. ;-)

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