[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Opaque storage
From: |
Pierre THIERRY |
Subject: |
Re: Opaque storage |
Date: |
Thu, 11 Jan 2007 18:52:35 +0100 |
User-agent: |
Mutt/1.5.13 (2006-08-11) |
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
--
address@hidden
OpenPGP 0xD9D50D8A
signature.asc
Description: Digital signature
- Re: Opaque storage, (continued)
- Re: Opaque storage, Pierre THIERRY, 2007/01/09
- Re: Opaque storage, Marcus Brinkmann, 2007/01/10
- Re: Opaque storage, Alan Grimes, 2007/01/10
- Re: Opaque storage, Pierre THIERRY, 2007/01/10
- Re: Opaque storage, Anton Tagunov, 2007/01/10
- Re: Opaque storage, Pierre THIERRY, 2007/01/10
- Re: Opaque storage, Pierre THIERRY, 2007/01/10
- Re: Opaque storage, Marcus Brinkmann, 2007/01/10
- Re: Opaque storage, Pierre THIERRY, 2007/01/10
- Re: Opaque storage, Marcus Brinkmann, 2007/01/11
- Re: Opaque storage,
Pierre THIERRY <=
- Re: Alternative network stack design, Tom Bachmann, 2007/01/08
- Re: Alternative network stack design (was: Re: Potential use case for opaque space bank: domain factored network stack, Jonathan S. Shapiro, 2007/01/07
Re: Potential use case for opaque space bank: domain factored network stack, Ludovic Courtès, 2007/01/15