Re: Opaque storage

[Marcus Brinkmann]

At Wed, 10 Jan 2007 04:03:23 +0100,
Pierre THIERRY <address@hidden> wrote:
> 
> [1  <multipart/signed (7bit)>]
> [1.1  <text/plain; us-ascii (quoted-printable)>]
> Scribit Marcus Brinkmann dies 10/01/2007 hora 02:57:
> > 1) In your proposal, it is only B that is unable to use "dangerous"
> > capabilities.  But if B is not trusted, then it makes sense to extend
> > this policy to all processes reached transitively by B, unless we have
> > external reason to assume that they are trustworthy.
> 
> No need. Let the magic of POLA apply. (I'll become a mystic supporter of
> POLA in a short time, believe me...)

Well, I don't believe in magic.
 
> > In other words, B can easily compromise your design by instantiating a
> > helper process and off-loading any dangerous activities to that helper
> > process.
> 
> I challenge you to sketch a precise scenario where it achieves that... B
> has not the needed authority.
> 
> To instantiate a process, B needs authority, but it has none, as
> certified by it's constructor. And even if it were given authority to
> instanciate other confined processes, it could only give them capabilies
> it holds. But it doesn't hold any dangerous capabilities, because the
> guard holds them.

Ah, sorry, I see where I got you wrong.  I missed this part in your mail:

  "Along with a (proxied) capability to S, and as part of the protocol to
   use S, B receives a capability c0 to use opaque storage, destined to S,
                                                            ^^^^^^^^^^^^^
   and marked dangerous to the reference monitor. The guard will keep c0
   and give to B a capability to itself c1 that is just a no-op (but it
   could also be used to notify A of the hostile character of B...).

   When B invokes the s1 capability to use S and includes the c1
   capability, G will substitute it with c0, thus giving S authority to use
   opaque storage."

This "destined to S" in your proposal appears to be exactly the
tagging that I proposed.  Don't you think so?

> > 6) On a more general note, I want to point out that the general
> > objective of my proposal is by no means new. [...] It is a general
> > design pattern, definitely useful and in fact very necessary under
> > some circumstances (again, auth protocol).
> 
> Where is the auth protocol needed?

To implement identity based access control, when a program A wants to
proof to a peer B that it has access to an identity without actually
handing it to B.

However, I take that comment back.  I still believe that there is some
similarity that is more than superficial, but on second thought it
does not seem to extend to the resource access level, only to the
identity management ("tagging") level of what we are discussing now.
Sorry for the confusion.

Thanks,
Marcus