[e-lang] A broken brand?
toby.murray at comlab.ox.ac.uk
Fri Mar 14 07:49:44 EDT 2008
On Thu, 2008-03-13 at 18:02 -0700, Mark Miller wrote:
> On Thu, Mar 13, 2008 at 2:56 PM, Toby Murray
> <toby.murray at comlab.ox.ac.uk> wrote:
> > The problem here is that we have two situations that we cannot really
> > distinguish. One of them is considered valid (holding the unsealer and a
> > proxy to the box) and the other is considered invalid (holding the
> > unsealer and a reference to an object that, when invoked, can cause the
> > box to be invoked). We have no way to state what the fundamental
> > difference between these two cases is, since the first is an instance of
> > the second. Yet we consider one valid and the other invalid.
> When thinking about (my broken adaptation of) MarcS' sealer/unsealer
> pattern and David's attack in the context of SCOLL, the issue that
> jumped out at me is the need to specify the authority provided by the
> innocent wrapper that's wrapping the box. It is this innocent wrapper
> that David is abusing. If this innocent wrapper intended to provide
> its clients the authority to obtain the box contents (given the
> unsealer), then David would indeed simply be utilizing authority he
> was intentionally given. However, the innocent wrapper's specification
> should be that it doesn't provide (to a client possessing the
> unsealer) the authority to obtain the box contents.
I think you've hit on the key issue here.
On the other hand, I wonder whether one could "work around" the issue as
Suppose we rewrite the unsealer so that it holds a reference to a
coercer. All boxes that the sealer creates can be coerced using the
unsealer's coercer to a direct reference to the original box. Then
before invoking the box, the unsealer first tries to coerce it using its
Now in the case of holding a proxy to a box, the coercion will work.
There are two cases to consider in David's attack.
1. The wrapper cannot be coerced, since it doesn't proxy the coercion
One would expect that this would be the case. I'll assume that David
agrees here. In this case, the attack is foiled.
2. The wrapper can be coerced, becase it chooses to proxy the box's
One would expect, then, that the wrapper is designed to provide its
clients the authority to unseal the box when the clients hold only the
unsealer. In this case, the attack is no attack at all and it of course
We have made the assumptions about the wrapper explicit by ensuing that
it can control whether or not the attack can succeed.
Whether this adds much I'm not sure though.
> This implies that the specification of the sealer/unsealer system
> should include that a relied-upon wrapper can be written that will
> obtain and utilize the box contents itself in a limited manner, but
> will not provide its unrelied-upon caller the authority to obtain the
> box contents.
Perhaps we write the specification such that the unsealer can only
unseal "valid" designations of boxes. We make "valid" explicit by saying
that a designation is "valid" if and only if it can be coerced to a box
(i.e. if an only if it proxies the box's coersion protocol). This
clearly distinguishes "valid" and "invalid" designations of boxes. It
effectively solves the problem of deciding when a subject "has the box".
It does involve complicating the logic of the brand though.
> Even with SCOLL, I admit that it's unlikely that a
> specification written in ignorance of this attack would think to
> specify this.
Indeed. This is why it might be best to avoid having to make such a
> It seems this issue is a great simple concrete example just beyond the
> bleeding edge of our ability to reason about authority. Research
More information about the e-lang