Re: Joins on capabilities that have passed through different membranes
Kenton Varda <[email protected]> Tue, 5 Jan 2016 10:19:34 -0800
| Newsgroups | gmane.comp.capabilities.general |
|---|---|
| Message-ID | <CAOP=4wgDEn1qWMX8kcRdjYQ_cajsnRMccJ2_KRVkCKAt30j9Qw@mail.gmail.com> |
--===============2839513817351445457== Content-Type: multipart/alternative; boundary=001a11440386b8c60405289a48ef --001a11440386b8c60405289a48ef Content-Type: text/plain; charset=UTF-8 The "join" operation I'm referring to is the one provided by E. http://erights.org/elib/equality/index.html http://erights.org/elib/equality/after-both.html It seems to be a fundamentally necessary tool for a few use cases. Mark describes the "grant matcher puzzle" as an example: http://erights.org/elib/equality/grant-matcher/index.html I'm not sure "Ask Bob" works for this use case: If I understand correctly, it could only tell you that Alice and Dana claim to agree on the identity of KEQD, but it does not protect against one of them performing a MITM after claiming agreement. Once the Grant Matcher determines that they agree, it still has to send the money somewhere. Without a "joined" capability, it must instead send it to one of the two capabilities provided by Alice and Dana. Whichever one it chooses, the person who provided that capability can potentially steal the money using a MITM. Ihab brings up a more common use case, which is actually already implemented in Sandstorm: Human users generally don't understand the concept of having multiple capabilities to the same document, possibly with different permissions. Human users also generally aren't anywhere near as susceptible to confused deputy attacks as everyone else. Therefore, as a convenience, when a human user receives two capabilities to the same document, we automatically join them. This join definitely takes union semantics, for obvious reasons. Note that in this use case, we are unioning not just revocation conditions, but also permissions/attenuations (e.g. read, write). But I was more thinking about the grant matcher type of use case here. Or, rather, I'm trying to determine if there is any use case for join where intersection semantics are preferred rather than union. I'm not too worried about implementation details at this point. I'm primarily trying to figure out what semantics are correct. A possible answer could be "union is always correct" and another could be "the caller needs to decide". -Kenton On Tue, Jan 5, 2016 at 8:24 AM, <[email protected]> wrote: > > On Tue, Jan 5, 2016 at 4:41 AM, David Bruant <[email protected]> wrote: > >> Can you provide a concrete example of why one would want to perform the >>> join instead of just using the two capabilities separately? >>> >> > I'm going to take a guess. This is a problem we talked about extensively > during the early parts of the Caja project, and discussed with our security > PMs. From what I recall, we did not have a good answer. > > * Let's say I have a document I own and have read/write access to. Let's > call my capability to it [rwdoc]. > > * I share a read-only cap to that document with Kenton. I say something > like, "Hey Kenton, check out this stuff I wrote up at [rodoc]. Regards." > > * Months later, Kenton replies to me, saying, "Hey Ihab, I think you need > to add the following information to [rodoc], because some new stuff came > up! Kthxbai." > > * The cap [rodoc] arrives in my user agent -- browser or whatever. Now > what? There is no simple "correct" solution. > > -> If my user agent automatically amplifies it to [rwdoc], that means the > agent has ambient authority. In fact, that's what happens with browsers and > cookies today! And when you make the situation a bit more complex, with > Kenton's original example, you end up with the joining problem he has > raised. > > -> If my user agent does nothing, then I have "two ways" to get to one > logical document, and we don't know how to explain this state of affairs to > end-users. > > I think this is a UX research problem. :) > > Ihab > > -- > Ihab A.B. Awad, Palo Alto, CA > > _______________________________________________ > cap-talk mailing list > [email protected] > http://www.eros-os.org/mailman/listinfo/cap-talk > > --001a11440386b8c60405289a48ef Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">The "join" operation I'm referring to is the= one provided by E.<div><br></div><div><a href=3D"http://erights.org/elib/e= quality/index.html">http://erights.org/elib/equality/index.html</a><br></di= v><div><a href=3D"http://erights.org/elib/equality/after-both.html">http://= erights.org/elib/equality/after-both.html</a><br></div><div><br></div><div>= It seems to be a fundamentally necessary tool for a few use cases. Mark des= cribes the "grant matcher puzzle" as an example:</div><div><br></= div><div><a href=3D"http://erights.org/elib/equality/grant-matcher/index.ht= ml">http://erights.org/elib/equality/grant-matcher/index.html</a><br></div>= <div><br></div><div>I'm not sure "Ask Bob" works for this use= case: If I understand correctly, it could only tell you that Alice and Dan= a claim to agree on the identity of KEQD, but it does not protect against o= ne of them performing a MITM after claiming agreement. Once the Grant Match= er determines that they agree, it still has to send the money somewhere. Wi= thout a "joined" capability, it must instead send it to one of th= e two capabilities provided by Alice and Dana. Whichever one it chooses, th= e person who provided that capability can potentially steal the money using= a MITM.</div><div><br></div><div>Ihab brings up a more common use case, wh= ich is actually already implemented in Sandstorm: Human users generally don= 't understand the concept of having multiple capabilities to the same d= ocument, possibly with different permissions. Human users also generally ar= en't anywhere near as susceptible to confused deputy attacks as everyon= e else. Therefore, as a convenience, when a human user receives two capabil= ities to the same document, we automatically join them. This join definitel= y takes union semantics, for obvious reasons. Note that in this use case, w= e are unioning not just revocation conditions, but also permissions/attenua= tions (e.g. read, write).<br></div><div><br></div><div>But I was more think= ing about the grant matcher type of use case here. Or, rather, I'm tryi= ng to determine if there is any use case for join where intersection semant= ics are preferred rather than union.</div><div><br></div><div>I'm not t= oo worried about implementation details at this point. I'm primarily tr= ying to figure out what semantics are correct. A possible answer could be &= quot;union is always correct" and another could be "the caller ne= eds to decide".</div><div><br></div><div>-Kenton</div></div><div class= =3D"gmail_extra"><br><div class=3D"gmail_quote">On Tue, Jan 5, 2016 at 8:24= AM, <span dir=3D"ltr"><<a href=3D"mailto:[email protected]" target= =3D"_blank">[email protected]</a>></span> wrote:<br><blockquote class= =3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd= ing-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D= "gmail_quote"><span class=3D"">On Tue, Jan 5, 2016 at 4:41 AM, David Bruant= <span dir=3D"ltr"><<a href=3D"mailto:[email protected]" target=3D"_bla= nk">[email protected]</a>></span> wrote:<br><blockquote class=3D"gmail_= quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1= ex"><span><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord= er-left:1px #ccc solid;padding-left:1ex">Can you provide a concrete example= of why one would want to perform the join instead of just using the two ca= pabilities separately?<br></blockquote></span></blockquote><div><br></div><= /span><div>I'm going to take a guess. This is a problem we talked about= extensively during the early parts of the Caja project, and discussed with= our security PMs. From what I recall, we did not have a good answer.</div>= <div><br></div><div>* Let's say I have a document I own and have read/w= rite access to. Let's call my capability to it [rwdoc].</div><div><br><= /div><div>* I share a read-only cap to that document with Kenton. I say som= ething like, "Hey Kenton, check out this stuff I wrote up at [rodoc]. = Regards."</div><div><br></div><div>* Months later, Kenton replies to m= e, saying, "Hey Ihab, I think you need to add the following informatio= n to [rodoc], because some new stuff came up! Kthxbai."</div><div><br>= </div><div>* The cap [rodoc] arrives in my user agent -- browser or whateve= r. Now what? There is no simple "correct" solution.</div><div><br= ></div><div>-> If my user agent automatically amplifies it to [rwdoc], t= hat means the agent has ambient authority. In fact, that's what happens= with browsers and cookies today! And when you make the situation a bit mor= e complex, with Kenton's original example, you end up with the joining = problem he has raised.</div><div><br></div><div>-> If my user agent does= nothing, then I have "two ways" to get to one logical document, = and we don't know how to explain this state of affairs to end-users.</d= iv><div><br></div><div>I think this is a UX research problem. :)</div><span= class=3D"HOEnZb"><font color=3D"#888888"><div><br></div><div>Ihab</div><di= v><br></div><div>--=C2=A0<br></div></font></span></div><span class=3D"HOEnZ= b"><font color=3D"#888888"><div>Ihab A.B. Awad, Palo Alto, CA</div> </font></span></div></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> --001a11440386b8c60405289a48ef-- --===============2839513817351445457== 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 --===============2839513817351445457==--