Re: Part 2: System Structure

[Bas Wijnen]

On Tue, May 23, 2006 at 10:15:44PM +0200, Pierre THIERRY wrote:
> Scribit Bas Wijnen dies 23/05/2006 hora 20:53:
> > This capability also allows checking that these banks are opaque.
> 
> In all your scenario, you seem to omit something: without the
> constructor mechanism, no process can verify anything accurately about
> any other process, except if all of the parents of it are to be trusted.

This is not quite correct.  If a process gives me a capability, I can check
things about it, no matter what the parents of the process are.  For
opaqueness, the chain of parents space bank-wise (of the process implementing
the capability, not of the one providing it) must be trusted.  Luckily
this chain of parents is usually short.  In my model, all space banks are
either used for creating sub-space banks, or for actual data (and code).  The
former type are all owned by user sessions (and the session manager), the
latter by programs.  You will get a capability to the former (for creating a
sub-space bank on it).  Then there are exactly two parents: The session's
space bank, and the primary space bank (owned by the session manager) directly
above that.

Things get a bit more complex when using it for debugging, such as when
starting a sub-Hurd.  But that is very useful in those cases as well.

> That is, except for a process spawned by the TCB, no capability can be
> trusted not to be faked or sniffed.

No no, this is not how it works.  It doesn't matter at all who spawned the
process.  It only matters who owns the space bank.  In my model, almost all
space banks are owned by the TCB.  (All except the ones that contain the code
and data.)  Thus, the parent-tree of processes is quite different from the
parent-tree of space banks.  The space bank tree is mostly flat, with just
some sub-space banks which are used for quotas (and these are also owned by
the TCB).

> And AFAIK, there is no mean for a
> process to check that it has been spawned by the TCB.

There is.  You can ask the TCB (with a capability that you received through
independent means, probably your own parent).  We have an "identify"
operation, which lets a server tell if a capbility is implemented by it.  I
didn't think too deep about an optimal protocol, but this would work, for
example:
- The program provides the server two capabilities, one to the session manager
  and one to the session.
- The server has a capability to its own session manager (which should be the
  same), and asks it if it is indeed the one which implements the
  user-provided capability.  If all is well, the answer will be "yes".
- Then it uses this user-provided capability to get a capability to the user's
  session.  Because the first capability was trusted, this is indeed a
  capability to the user's session (or at least a session which allows the
  client to use it).
- It then uses this capability to check that the second capability the user
  provided did indeed come from the same session.  If so, it is trusted to not
  lie.
- Then this second capability is used to create opaque memory.

> But when a process is spawned by a constructor and given some
> capabilities to the TCB that the requestor cannot spy or alter, it is be
> given the ability to check properties of it's environment accurately.

Checking the space bank must be done before using it.  In Jonathan's model,
this is done in the constructor, which seems like something which doesn't
belong there to me.  But that's because my default is transparent space banks,
and so opaqueness is an "extra" (which should be implemented as close to the
user as possible).

> Am I wrong on anything here?

You seemed to be forgetting that without a constructor, we can still have an
"identify" operation.  This is the check a program can do to see if a
capability is implemented by itself.  It can provide this check to clients
(and it can lie about the result, so you need to trust the server before using
the result).

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