Re: Joins on capabilities that have passed through different membranes
Kenton Varda <[email protected]> Tue, 5 Jan 2016 12:01:48 -0800
| Newsgroups | gmane.comp.capabilities.general |
|---|---|
| Message-ID | <CAOP=4whgVMBLEHacxAN=vd4W=mD4TmLqmseqbe13FvSFG9nnMg@mail.gmail.com> |
--===============0002499737849357178== Content-Type: multipart/alternative; boundary=001a114123c65f7fb105289bb69c --001a114123c65f7fb105289bb69c Content-Type: text/plain; charset=UTF-8 On Tue, Jan 5, 2016 at 11:14 AM, Alan Karp <[email protected]> wrote: > 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. > Yes, but Ihab is not a computer. He can look at the document and understand what the document is and what effect my requested change will have. He can decide if this change seem suspicious. Moreover if I ask him to make a change that I obviously could have made myself, he's going to wonder why I asked him to do it, and probably catch on to the fact that I don't actually have said permission after all. This isn't foolproof, obviously. Social engineering is a thing. But social engineering could also work against SCoopFS based on titles, as you describe. Humans are relatively unlikely to be fooled just because I sent them a thing that looks like a capability, especially if they aren't capability-based security experts. :) Humans, meanwhile, are much worse at managing multiple capabilities to the same object than computers are. So in the interest of UX, we make a compromise by auto-joining capabilities when they land in a human's capability store. 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). > I really doubt that a user would understand that landing on the read-only view implies that the sender only had read access, if an edit button or tab is readily visible and is normally part of the UI. The user would merely think: "Huh, why am I on the read-only view? I'll switch to edit mode so I can make the requested edit." > 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. > I see what you're going for here but my intuition is that users wouldn't get it, and that this UX doesn't scale well with complexity. Consider what happens when you add a "can comment" permission. Do we now have three tabs: "read-only", "read+comment", and "edit"? I agree that it's useful for the sharer to be able to see exactly what they are sharing, but probably this needs to be accomplished via a UI that is explicitly offering to simulate the document with different permissions. Facebook offers something like this to view your own profile from the perspective of another user, for example. -Kenton > > -------------- > 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 >> >> > > _______________________________________________ > cap-talk mailing list > [email protected] > http://www.eros-os.org/mailman/listinfo/cap-talk > > --001a114123c65f7fb105289bb69c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T= ue, Jan 5, 2016 at 11:14 AM, Alan Karp <span dir=3D"ltr"><<a href=3D"mai= lto:[email protected]" target=3D"_blank">[email protected]</a>></spa= n> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b= order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"= gmail_extra"><div class=3D"gmail_quote"><div>I'm not so sure that users= aren't susceptible to confused deputy attacks without some additional = context.=C2=A0 In SCoopFS, Kenton would have to send a message to Ihab sayi= ng, "Please make this change on my behalf." =C2=A0That message wo= uld 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 chang= e.=C2=A0 As I understand what you do in Sandstorm, Kenton uses his capabili= ty to make the request, which gets merged with Ihab's.=C2=A0 At this po= int, it appears to Ihab that he is making the change using Kenton's cap= ability even though he's using permissions from his own.</div></div></d= iv></div></blockquote><div><br></div><div>Yes, but Ihab is not a computer. = He can look at the document and understand what the document is and what ef= fect my requested change will have. He can decide if this change seem suspi= cious. Moreover if I ask him to make a change that I obviously could have m= ade myself, he's going to wonder why I asked him to do it, and probably= catch on to the fact that I don't actually have said permission after = all.</div><div><br></div><div>This isn't foolproof, obviously. Social e= ngineering is a thing. But social engineering could also work against SCoop= FS based on titles, as you describe. Humans are relatively unlikely to be f= ooled just because I sent them a thing that looks like a capability, especi= ally if they aren't capability-based security experts. :)</div><div><br= ></div><div>Humans, meanwhile, are much worse at managing multiple capabili= ties to the same object than computers are. So in the interest of UX, we ma= ke a compromise by auto-joining capabilities when they land in a human'= s capability store.</div><div><br></div><blockquote class=3D"gmail_quote" s= tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div= dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div>Mar= c Stiegler came up with a clever 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 with his own, he sees a rw view.=C2=A0 In eit= her case, he see the same document, which reduces any possible confusion.= =C2=A0 Since Ihab does have write permission, his UI has an Edit button (ac= tually a tab in Stiegler's UI).<br></div></div></div></div></blockquote= ><div><br></div><div>I really doubt that a user would understand that landi= ng on the read-only view implies that the sender only had read access, if a= n edit button or tab is readily visible and is normally part of the UI. The= user would merely think: "Huh, why am I on the read-only view? I'= ll switch to edit mode so I can make the requested edit."</div><div>= =C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo= rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"g= mail_extra"><div class=3D"gmail_quote"><div></div><div>The same views are u= sed for sharing, WYSIWYS (What You See Is What You Share).=C2=A0 If you cli= ck the Share button while in the Edit view, you share rw.=C2=A0 If you clic= k in the Browse view, you share ro.=C2=A0 We need to do more experiments to= see how easy that is for people to understand, but at least there's a = concise explanation.<br></div></div></div></div></blockquote><div><br></div= ><div>I see what you're going for here but my intuition is that users w= ouldn't get it, and that this UX doesn't scale well with complexity= . Consider what happens when you add a "can comment" permission. = Do we now have three tabs: "read-only", "read+comment",= and "edit"?</div><div><br></div><div>I agree that it's usefu= l for the sharer to be able to see exactly what they are sharing, but proba= bly this needs to be accomplished via a UI that is explicitly offering to s= imulate the document with different permissions. Facebook offers something = like this to view your own profile from the perspective of another user, fo= r example.</div><div><br></div><div>-Kenton</div><div>=C2=A0</div><blockquo= te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so= lid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div clas= s=3D"gmail_quote"><div></div><div><br></div><div><div>--------------<br>Ala= n Karp</div></div></div></div></div><div class=3D"gmail_extra"><br clear=3D= "all"><div><div><br>--------------<br>Alan Karp</div></div><div><div class= =3D"h5"> <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><font color=3D"#888888"><div><br></div><d= iv>--=C2=A0<br></div></font></span></font></span></div><span><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><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]" 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></blockquote></div><br></div></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></div> --001a114123c65f7fb105289bb69c-- --===============0002499737849357178== 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 --===============0002499737849357178==--