Re: Joins on capabilities that have passed through different membranes
Alan Karp <[email protected]> Tue, 5 Jan 2016 14:28:45 -0800
| Newsgroups | gmane.comp.capabilities.general |
|---|---|
| Message-ID | <CANpA1Z3WAR1NQoKjaVd42NVnqdMk2eMHxAZRR+ODAGNZYyrmwQ@mail.gmail.com> |
--===============8784555657157305206== Content-Type: multipart/alternative; boundary=001a113fb29ebd9f4905289dc293 --001a113fb29ebd9f4905289dc293 Content-Type: text/plain; charset=UTF-8 On Tue, Jan 5, 2016 at 12:01 PM, Kenton Varda <[email protected]> wrote: > 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. > > I'm more concerned that Ihab will pass the merged capability as an argument to some function, perhaps by inserting it into a field in the UI > 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. > > I think Marc Stiegler might disagree. He's using this pattern in DecideRight2. > 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." > Yes, but if instead of editing he clicks the Share button to send the document as an argument to a program, he'll be using Kenton's permissions, as he should. > > >> 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 can get complicated really fast, but it seems to work for a small set of permissions on the object. Unfortunately, doing user studies at HP was virtually impossible, so we're not sure. Clearly, we need something different for more than a few permissions. -------------- Alan Karp --001a113fb29ebd9f4905289dc293 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 12:01 PM, Kenton Varda <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: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 class=3D"gmail_extra= "><div class=3D"gmail_quote">On Tue, Jan 5, 2016 at 11:14 AM, Alan Karp <sp= an dir=3D"ltr"><<a href=3D"mailto:[email protected]" target=3D"_blank"= >[email protected]</a>></span> wrote:<br><blockquote class=3D"gmail_qu= ote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-co= lor:rgb(204,204,204);border-left-style: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 witho= ut some additional context.=C2=A0 In SCoopFS, Kenton would have to send a m= essage to Ihab saying, "Please make this change on my behalf." = =C2=A0That message would not include Kenton's capability; it just refer= s to the document by name.=C2=A0 Ihab must explicitly select his rw capabil= ity to make the change.=C2=A0 As I understand what you do in Sandstorm, Ken= ton uses his capability to make the request, which gets merged with Ihab= 9;s.=C2=A0 At this point, it appears to Ihab that he is making the change u= sing Kenton's capability even though he's using permissions from hi= s own.</div></div></div></div></blockquote><div><br></div><div>Yes, but Iha= b is not a computer. He can look at the document and understand what the do= cument is and what effect my requested change will have. He can decide if t= his change seem suspicious. Moreover if I ask him to make a change that I o= bviously could have made myself, he's going to wonder why I asked him t= o do it, and probably catch on to the fact that I don't actually have s= aid permission after all.</div><div><br></div></div></div></div></blockquot= e><div>I'm more concerned that Ihab will pass the merged capability as = an argument to some function, perhaps by inserting it into a field in the U= I=C2=A0</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"ma= rgin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,= 204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div class= =3D"gmail_extra"><div class=3D"gmail_quote"><div></div><div>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 a= re relatively unlikely to be fooled just because I sent them a thing that l= ooks like a capability, especially if they aren't capability-based secu= rity experts. :)</div><div><br></div><div>Humans, meanwhile, are much worse= at managing multiple capabilities to the same object than computers are. S= o in the interest of UX, we make a compromise by auto-joining capabilities = when they land in a human's capability store.</div><div><br></div></div= ></div></div></blockquote><div>I think Marc Stiegler might disagree.=C2=A0 = He's using this pattern in DecideRight2.</div><div>=C2=A0</div><blockqu= ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-wid= th:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-l= eft:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_qu= ote"><div></div><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 class=3D"gmail_extra= "><div class=3D"gmail_quote"><div>Marc Stiegler came up with a clever UI af= fordance to make all this clear.=C2=A0 If Ihab views the document with Kent= on's capability, Ihab sees a ro view.=C2=A0 If Ihab opens it with his o= wn, he sees a rw view.=C2=A0 In either case, he see the same document, whic= h reduces any possible confusion.=C2=A0 Since Ihab does have write permissi= on, his UI has an Edit button (actually a tab in Stiegler's UI).<br></d= iv></div></div></div></blockquote><div><br></div><div>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 an= d is normally part of the UI. The user would merely think: "Huh, why a= m I on the read-only view? I'll switch to edit mode so I can make the r= equested edit."=C2=A0</div></div></div></div></blockquote><div><br></d= iv><div>Yes, but if instead of editing he clicks the Share button to send t= he document as an argument to a program, he'll be using Kenton's pe= rmissions, as he should.</div><blockquote class=3D"gmail_quote" style=3D"ma= rgin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,= 204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div class= =3D"gmail_extra"><div class=3D"gmail_quote"><div>=C2=A0</div><blockquote cl= ass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px= ;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1e= x"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><= div></div><div>The same views are used for sharing, WYSIWYS (What You See I= s What You Share).=C2=A0 If you click the Share button while in the Edit vi= ew, you share rw.=C2=A0 If you click in the Browse view, you share ro.=C2= =A0 We need to do more experiments to see how easy that is for people to un= derstand, 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 wouldn't get it, and that this UX d= oesn'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></di= v></div></blockquote><div><br></div><div>I agree that it can get complicate= d really fast, but it seems to work for a small set of permissions on the o= bject.=C2=A0 Unfortunately, doing user studies at HP was virtually impossib= le, so we're not sure.=C2=A0 Clearly, we need something different for m= ore than a few permissions.</div><div><div><div class=3D"gmail_signature"><= br>--------------<br>Alan Karp</div></div></div></div></div></div> --001a113fb29ebd9f4905289dc293-- --===============8784555657157305206== 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 --===============8784555657157305206==--