Re: Joins on capabilities that have passed through different membranes
Alan Karp <[email protected]> Tue, 5 Jan 2016 11:14:31 -0800
| Newsgroups | gmane.comp.capabilities.general |
|---|---|
| Message-ID | <CANpA1Z10+nRZCDEwB0yGQZX7+Oyx-UzO6kJD0dwXZL876FCuBw@mail.gmail.com> |
--===============1058223426467227354== Content-Type: multipart/alternative; boundary=001a11401a9017e5fd05289b0cc0 --001a11401a9017e5fd05289b0cc0 Content-Type: text/plain; charset=UTF-8 On Tue, Jan 5, 2016 at 10:19 AM, Kenton Varda <[email protected]> wrote: > > > 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. > Correct, for exactly the reason you give. > > 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). > > I'm not so sure that users aren't susceptible to confused deputy attacks without some additional context. In SCoopFS, Kenton would have to send a message to Ihab saying, "Please make this change on my behalf." That message would not include Kenton's capability; it just refers to the document by name. Ihab must explicitly select his rw capability to make the change. As I understand what you do in Sandstorm, Kenton uses his capability to make the request, which gets merged with Ihab's. At this point, it appears to Ihab that he is making the change using Kenton's capability even though he's using permissions from his own. Marc Stiegler came up with a clever UI affordance to make all this clear. If Ihab views the document with Kenton's capability, Ihab sees a ro view. If Ihab opens it with his own, he sees a rw view. In either case, he see the same document, which reduces any possible confusion. Since Ihab does have write permission, his UI has an Edit button (actually a tab in Stiegler's UI). The same views are used for sharing, WYSIWYS (What You See Is What You Share). If you click the Share button while in the Edit view, you share rw. If you click in the Browse view, you share ro. We need to do more experiments to see how easy that is for people to understand, but at least there's a concise explanation. -------------- Alan Karp -------------- Alan Karp On Tue, Jan 5, 2016 at 10:19 AM, Kenton Varda <[email protected]> wrote: > 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 >> >> > > _______________________________________________ > cap-talk mailing list > [email protected] > http://www.eros-os.org/mailman/listinfo/cap-talk > > --001a11401a9017e5fd05289b0cc0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">= On Tue, Jan 5, 2016 at 10:19 AM, Kenton Varda <span dir=3D"ltr"><<a href= =3D"mailto:[email protected]" target=3D"_blank">[email protected]</a>&g= t;</span> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0= px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-le= ft-style:solid;padding-left:1ex"><div dir=3D"ltr"><div><br></div><div>I'= ;m not sure "Ask Bob" works for this use case: If I understand co= rrectly, it could only tell you that Alice and Dana claim to agree on the i= dentity of KEQD, but it does not protect against one of them performing a M= ITM after claiming agreement.=C2=A0</div></div></blockquote><div><br></div>= <div>Correct, for exactly the reason you give.=C2=A0</div><blockquote class= =3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;bo= rder-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">= <div dir=3D"ltr"><div><br></div><div>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 sam= e document, possibly with different permissions. Human users also generally= aren't anywhere near as susceptible to confused deputy attacks as ever= yone else. Therefore, as a convenience, when a human user receives two capa= bilities to the same document, we automatically join them. This join defini= tely takes union semantics, for obvious reasons. Note that in this use case= , we are unioning not just revocation conditions, but also permissions/atte= nuations (e.g. read, write).<br></div><div><br></div></div></blockquote><di= v>I'm not so sure that users aren't susceptible to confused deputy = attacks without some additional context.=C2=A0 In SCoopFS, Kenton would hav= e to send a message to Ihab saying, "Please make this change on my beh= alf." =C2=A0That message would not include Kenton's capability; it= just refers to the document by name.=C2=A0 Ihab must explicitly select his= rw capability to make the change.=C2=A0 As I understand what you do in San= dstorm, Kenton uses his capability to make the request, which gets merged w= ith Ihab's.=C2=A0 At this point, it appears to Ihab that he is making t= he change using Kenton's capability even though he's using permissi= ons from his own.</div><div><br></div><div>Marc Stiegler came up with a cle= ver UI affordance to make all this clear.=C2=A0 If Ihab views the document = with Kenton's capability, Ihab sees a ro view.=C2=A0 If Ihab opens it w= ith his own, he sees a rw view.=C2=A0 In either case, he see the same docum= ent, which reduces any possible confusion.=C2=A0 Since Ihab does have write= permission, his UI has an Edit button (actually a tab in Stiegler's UI= ).</div><div><br></div><div>The same views are used for sharing, WYSIWYS (W= hat You See Is What You Share).=C2=A0 If you click the Share button while i= n the Edit view, you share rw.=C2=A0 If you click in the Browse view, you s= hare ro.=C2=A0 We need to do more experiments to see how easy that is for p= eople to understand, but at least there's a concise explanation.</div><= div><br></div><div><div class=3D"gmail_signature">--------------<br>Alan Ka= rp</div></div></div></div></div><div class=3D"gmail_extra"><br clear=3D"all= "><div><div class=3D"gmail_signature"><br>--------------<br>Alan Karp</div>= </div> <br><div class=3D"gmail_quote">On Tue, Jan 5, 2016 at 10:19 AM, Kenton Vard= a <span dir=3D"ltr"><<a href=3D"mailto:[email protected]" target=3D"_b= lank">[email protected]</a>></span> wrote:<br><blockquote class=3D"gma= il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef= t:1ex"><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/equality/index.html" target=3D"_blank">http://erights.org/elib/equali= ty/index.html</a><br></div><div><a href=3D"http://erights.org/elib/equality= /after-both.html" target=3D"_blank">http://erights.org/elib/equality/after-= both.html</a><br></div><div><br></div><div>It seems to be a fundamentally n= ecessary tool for a few use cases. Mark describes the "grant matcher p= uzzle" as an example:</div><div><br></div><div><a href=3D"http://erigh= ts.org/elib/equality/grant-matcher/index.html" target=3D"_blank">http://eri= ghts.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 un= derstand correctly, it could only tell you that Alice and Dana claim to agr= ee on the identity of KEQD, but it does not protect against one of them per= forming 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 capabili= ties provided by Alice and Dana. Whichever one it chooses, the person who p= rovided that capability can potentially steal the money using a MITM.</div>= <div><br></div><div>Ihab brings up a more common use case, which is actuall= y already implemented in Sandstorm: Human users generally don't underst= and the concept of having multiple capabilities to the same document, possi= bly with different permissions. Human users also generally aren't anywh= ere near as susceptible to confused deputy attacks as everyone else. Theref= ore, as a convenience, when a human user receives two capabilities to the s= ame 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. re= ad, write).<br></div><div><br></div><div>But I was more thinking about the = grant matcher type of use case here. Or, rather, I'm trying to determin= e if there is any use case for join where intersection semantics are prefer= red rather than union.</div><div><br></div><div>I'm not too worried abo= ut 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&= quot;.</div><div><br></div><div>-Kenton</div></div><div class=3D"gmail_extr= a"><br><div class=3D"gmail_quote">On Tue, Jan 5, 2016 at 8:24 AM, <span di= r=3D"ltr"><<a href=3D"mailto:[email protected]" target=3D"_blank">ihab= [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:1ex"><di= v dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote"><sp= an>On Tue, Jan 5, 2016 at 4:41 AM, David Bruant <span dir=3D"ltr"><<a hr= ef=3D"mailto:[email protected]" target=3D"_blank">[email protected]</a>&g= t;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0= .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><blockquote class= =3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd= ing-left:1ex">Can you provide a concrete example of why one would want to p= erform the join instead of just using the two capabilities 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 ear= ly parts of the Caja project, and discussed with our security PMs. From wha= t I recall, we did not have a good answer.</div><div><br></div><div>* Let&#= 39;s say I have a document I own and have read/write access to. Let's c= all my capability to it [rwdoc].</div><div><br></div><div>* I share a read-= only cap to that document with Kenton. I say something like, "Hey Kent= on, check out this stuff I wrote up at [rodoc]. Regards."</div><div><b= r></div><div>* 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."</div><div><br></div><div>* The cap [rodoc= ] arrives in my user agent -- browser or whatever. Now what? There is no si= mple "correct" solution.</div><div><br></div><div>-> If my use= r agent automatically amplifies it to [rwdoc], that means the agent has amb= ient 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.</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 t= o explain this state of affairs to end-users.</div><div><br></div><div>I th= ink this is a UX research problem. :)</div><span><font color=3D"#888888"><d= iv><br></div><div>Ihab</div><span class=3D"HOEnZb"><font color=3D"#888888">= <div><br></div><div>--=C2=A0<br></div></font></span></font></span></div><sp= an class=3D"HOEnZb"><font color=3D"#888888"><span><font color=3D"#888888"><= div>Ihab A.B. Awad, Palo Alto, CA</div> </font></span></font></span></div></div><span class=3D"HOEnZb"><font color= =3D"#888888"> <br>_______________________________________________<br> cap-talk mailing list<br> <a href=3D"mailto:[email protected]" target=3D"_blank">cap-talk@mai= l.eros-os.org</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></font></span></blockquote></div><br></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> --001a11401a9017e5fd05289b0cc0-- --===============1058223426467227354== 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 --===============1058223426467227354==--