Re: Opaque storage

[Marcus Brinkmann]

At Wed, 10 Jan 2007 00:56:25 +0100,
Pierre THIERRY <address@hidden> wrote:
> 
> Scribit Marcus Brinkmann dies 08/01/2007 hora 12:10:
> > You seem to be missing that in the discussed scenario we have three
> > processes A, B, and S, where the delegation chain is "A->B->S", and A
> > trusts S with a certain resource (like opaque allocation) but not B.
> 
> There's a very easy way to achieve that, without even A being able to
> inspect B (so I'll describe it with a constructor):
> 
> A instantiates process B with B's constructor, and checks that B has no
> extra authority. It then instantiate a reference monitor guard process
> G, and gives B a capability to G that mediates access to A. All
> authority B will ask for will be asked through that reference monitor.
> 
> The reference monitor's role is to keep any capability marked as
> dangerous that B would receive and only give to B a no-op capability to
> G. Whenever B gives the no-op capability to another process outside the
> reference monitor, then the original capability is substituted to it.
> Capabilities not marked dangerous are proxied by G to be able to do the
> substitution.

Your proposal makes sense, but there are a couple of comments to make.

0) I agree that it doesn't matter if B is inspectable or not (in
   either proposal).

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.
   In other words, B can easily compromise your design by
   instantiating a helper process and off-loading any dangerous
   activities to that helper process.  The automatic translation by G
   to _any_ external process will ensure that.

2) This can be fixed, but it seems to me only by the sort of tagging
   you tried to prevent.  I didn't look hard for other solutions in
   this particular scenario, though.

3) In case you do fix it by tagging as I described it, which can
   happen in G, you will end up with a more general version of my
   proposal.  You have shown what I claimed earlier, that one can
   implement this even without support in the server S.  I agree, and
   support the idea that this could be a reasonable tool in some use
   cases.  It definitely should be added to the toolbox for
   consideration, with the modification called for by comment 1)
   above.

4) I would say that this is the power of virtualization, not of POLA.
   But I don't insist.

5) Tagging is not required for my proposal to work, it is only
   required if the resource manager is disjunct from the service that
   should be able to use the resource (as is the case in your example,
   as the resource manager would be G).  If both are identical, no
   tagging needs to occur.  For practical reasons, it may be advisable
   to allows do it in this manner, although this increases resource
   partitioning.  There are some non-obvious trade-off decisions to
   make here.

6) On a more general note, I want to point out that the general
   objective of my proposal is by no means new.  We already use it for
   identity management, where you can proof your identity to an
   untrusted process without giving away your identity capability.
   This is realized in the auth protocol of the Hurd.  This is an
   instance of the proposal which does not use tagging.  It is a
   general design pattern, definitely useful and in fact very
   necessary under some circumstances (again, auth protocol).

> When B needs access to trusted service process S, it asks for it, and if
> A hands a capability s0 to S, not marked dangerous, it will then be
> proxied by G, that would give B a s1 capability to itself.
> 
> 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.
> 
> You'll note that this doesn't need the introduction of any ACL like
> tagging, and nowhere identity of processes is known. It's just one of
> those scenarios where POLA shows it's incredible power (it took me about
> an hour to sketch it, and I'm just dazzled by it).
> 
> The guard is a very small process pretty straightforward to implement,
> AFAICT, and needs no special kernel support. It's sufficiently simple
> that I'm confident it could be proven to be correct pretty easily (it's
> only loop would in the access of a data structure holding capabilities
> to be compared, and we know proven lists, and the rest is only about
> value comparison).

Thanks,
Marcus