Re: Joins on capabilities that have passed through different membranes

--===============9097745060746755121==
Content-Type: multipart/alternative; boundary=001a113fb45cf1791005288eca05

--001a113fb45cf1791005288eca05
Content-Type: text/plain; charset=UTF-8

I don't think unification makes sense.  In fact, it might even lead to a
confused deputy vulnerability.


--------------
Alan Karp

On Mon, Jan 4, 2016 at 5:53 PM, Kenton Varda <[email protected]> wrote:

> Hi Mark and cap-talk,
>
> I'm interested to know if you've thought about the following problem:
>
> You want to perform a join on two capabilities A and B, which were
> obtained from Alice and Bob respectively. Semantically, the two
> capabilities point to the same object, in that the messages passed to
> either one are ultimately routed to the same place. However, the two
> capabilities have different conditions under which they become revoked,
> because the original creator of the capability wanted to maintain the
> ability to revoke Alice's and Bob's access independently. Therefore,
> capabilities A and B are not really pointing to the same object. So, what
> happens when you join them?
>
> The naive answer seems to be "they can't be joined because they're not the
> same". However, this answer seems highly problematic in practice.
>
> It seems to me that it is necessary to separate the notion of the endpoint
> object to which the capabilities point from the notion of
> restrictions/requirements added on top of them (where cap A has the
> requirement "Alice's access has not been revoked" and cap B has the
> requirement "Bob's access has not been revoked"). When joining two
> capabilities -- as long as the endpoint is the same, then the requirements
> must be "merged".
>
> "Merging" requirements could either mean taking the intersection (the
> joined capability is revoked if either original capability is revoked) or
> the union (the joined capability is revoked if *both* inputs are revoked).
> Intuitively, intersection seems more intuitive, but it means that any one
> party to the join can subsequently cause an outage of the joined capability
> by revoking their own input, which seems problematic in practical use
> cases. E.g. in the escrow case, if Alice owes Bob money upon completion of
> a contract, Alice could disrupt the contract capability just before it
> becomes complete so that the escrow agent never pays out. I haven't thought
> of any serious problems with taking the union of the requirements instead.
> Alternatively, it could be up to the entity performing the join to specify
> intersection or union, but if one or the other is almost always correct I'd
> rather not expose this additional cognitive overhead to developers.
>
> -Kenton
>
> _______________________________________________
> cap-talk mailing list
> [email protected]
> http://www.eros-os.org/mailman/listinfo/cap-talk
>
>

--001a113fb45cf1791005288eca05
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I don&#39;t think unification makes sense.=C2=A0 In fact, =
it might even lead to a confused deputy vulnerability. =C2=A0=C2=A0</div><d=
iv class=3D"gmail_extra"><br clear=3D"all"><div><div class=3D"gmail_signatu=
re"><br>--------------<br>Alan Karp</div></div>
<br><div class=3D"gmail_quote">On Mon, Jan 4, 2016 at 5:53 PM, Kenton Varda=
 <span dir=3D"ltr">&lt;<a href=3D"mailto:[email protected]" target=3D"_bl=
ank">[email protected]</a>&gt;</span> wrote:<br><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex"><div dir=3D"ltr">Hi Mark and cap-talk,<div><br></div><div>I&#39;m int=
erested to know if you&#39;ve thought about the following problem:</div><di=
v><br></div><div>You want to perform a join on two capabilities A and B, wh=
ich were obtained from Alice and Bob respectively. Semantically, the two ca=
pabilities point to the same object, in that the messages passed to either =
one are ultimately routed to the same place. However, the two capabilities =
have different conditions under which they become revoked, because the orig=
inal creator of the capability wanted to maintain the ability to revoke Ali=
ce&#39;s and Bob&#39;s access independently. Therefore, capabilities A and =
B are not really pointing to the same object. So, what happens when you joi=
n them?</div><div><br></div><div>The naive answer seems to be &quot;they ca=
n&#39;t be joined because they&#39;re not the same&quot;. However, this ans=
wer seems highly problematic in practice.</div><div><br></div><div>It seems=
 to me that it is necessary to separate the notion of the endpoint object t=
o which the capabilities point from the notion of restrictions/requirements=
 added on top of them (where cap A has the requirement &quot;Alice&#39;s ac=
cess has not been revoked&quot; and cap B has the requirement &quot;Bob&#39=
;s access has not been revoked&quot;). When joining two capabilities -- as =
long as the endpoint is the same, then the requirements must be &quot;merge=
d&quot;.</div><div><br></div><div>&quot;Merging&quot; requirements could ei=
ther mean taking the intersection (the joined capability is revoked if eith=
er original capability is revoked) or the union (the joined capability is r=
evoked if *both* inputs are revoked). Intuitively, intersection seems more =
intuitive, but it means that any one party to the join can subsequently cau=
se an outage of the joined capability by revoking their own input, which se=
ems problematic in practical use cases. E.g. in the escrow case, if Alice o=
wes Bob money upon completion of a contract, Alice could disrupt the contra=
ct capability just before it becomes complete so that the escrow agent neve=
r pays out. I haven&#39;t thought of any serious problems with taking the u=
nion of the requirements instead. Alternatively, it could be up to the enti=
ty performing the join to specify intersection or union, but if one or the =
other is almost always correct I&#39;d rather not expose this additional co=
gnitive overhead to developers.</div><span class=3D"HOEnZb"><font color=3D"=
#888888"><div><br></div><div>-Kenton</div></font></span></div>
<br>_______________________________________________<br>
cap-talk mailing list<br>
<a href=3D"mailto:[email protected]">[email protected]</a><=
br>
<a href=3D"http://www.eros-os.org/mailman/listinfo/cap-talk" rel=3D"norefer=
rer" target=3D"_blank">http://www.eros-os.org/mailman/listinfo/cap-talk</a>=
<br>
<br></blockquote></div><br></div>

--001a113fb45cf1791005288eca05--

--===============9097745060746755121==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
cap-talk mailing list
[email protected]
http://www.eros-os.org/mailman/listinfo/cap-talk

--===============9097745060746755121==--