Scribit Marcus Brinkmann dies 11/01/2007 hora 13:06:
> I am fine with that description.  To explain where B got it from: In
> any non-trivial scenario B might have gotten the capability from the
> user as the result of an open() operation via the powerbox, and the
> user provided a capability it got from another user.

You somewhat still forget POLA: B, as described, has no authority to a
powerbox. If you want to introduce the powerbox, it has to be known how
B acquire such a capability.

If the powerbox is mediated by the reference monitor and their is no
other protection, C will be out of it, and would receive s0 and x0
instead of g_s0 and g_x0. If the powerbox is not mediated by the
reference monitor, C would just be in it and the second scenario I
described applies.

> > Obviously C is able to use S, but not opaque storage itself. If it
> > communicates with B on a peer-to-peer basis, then it's just behind
> > the reference monitor. Still, G has no knowledge of the identities
> > of the processes involved.
> 
> This only works if C trusts B in the sense that it is willing to use
> the service under the name g_s0 introduced by B to C.

Well, there are no names in the scenario, only capabilities. If C
doesn't trust B, we are in a totally different scenario, and to be
studied C's authority and state should be precisely described.

If C is out of the reference monitor without any other protection, it
can have it's own capability to S, and if it is given the opaque storage
by B, it would indeed receive x0, not g_x0.

> It does not work if C wants to use the resource with a service that it
> got from somewhere else (for example, its own user shell).

Then it has to be described how B or C got a capability to the other,
because it determines what kind of protection or mediation will occur.

> This may be sufficient in some cases, but not in others.  Especially,
> it is not sufficient in cases of mutually suspicious collaboration.

If there has to be mutually suspicious collaboration between B and C, a
capability between them has to go through the reference monitor and it
works.

Precisely,
Pierre
-- 
[EMAIL PROTECTED]
OpenPGP 0xD9D50D8A

Attachment: signature.asc
Description: Digital signature

_______________________________________________
L4-hurd mailing list
L4-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/l4-hurd

Reply via email to