Re: Fwd: Fwd: Draft Proposed Standard SES (Secure EcmaScript)
"Mark S. Miller" <[email protected]> Mon, 21 Mar 2016 11:11:20 -0700
| Newsgroups | gmane.comp.capabilities.general |
|---|---|
| Message-ID | <CABHxS9jW4YLgmjz55o7=dxX6U=BJ-Tau9GhOA0sY3rBYMmvnhg@mail.gmail.com> |
--===============5870677763833814625== Content-Type: multipart/alternative; boundary=089e011609501588f8052e93061b --089e011609501588f8052e93061b Content-Type: text/plain; charset=UTF-8 On Sun, Mar 20, 2016 at 12:16 AM, Matt Rice <[email protected]> wrote: > > Not really familiar with javascript, but to slightly modify one of > your examples from one of your talks > > "use strict"; > > var count = 0; > > function makeCounter() { > // Moved var count = 0 from here to above > // appears to be valid strict javascript afaict > return def({ > incr: function() { return ++count;}, > decr: function () { return --count;} > }); > } > with the comment in the bottom of the slide: > "A tamper-proof record of lexical closures encapsulating state is a > defensive object" > > so this is 'defensive' rather than 'confined', Hi Matt, thanks for reminding me of that! As a result, I have added a short summary section at the beginning of https://github.com/FUDCo/ses-realm , using that example to explain the difference between the "offensive code problem" (which confinement addresses) and the "defensive code problem" which this document had not adequately explained. Please have a look. > confinement then > happens through multiple evaluations of the source code (rather than > the evaluator causing error due to the evaluation of the function > makeCounter being called in a context where the 'count' variable does > not exist, did I get that correct? > Yes, that is correct as stated, but see the answer to your next question. In general, confinement issues need to leverage what my thesis calls "open loaders" which obey "loader isolation", as that is how you can safely load new code from potential adversaries into an already running system. The "confine" function I propose, as well as the "eval" function and "Function" constructor of the proto-SES realm, are such safe loaders. Since this document is JavaScript centric, I'm using the term "evaluator" for all of these rather than "loader". E and Joe-E are ocap languages with additional mechanisms to test that an untrusted already-loaded allegedly transitively immutable object actually is (by the DeepFrozen and Immutable auditors, respectively). Given these mechanisms, you can also be sure that objects make by those transitively immutable objects are isolated from each other. However, we do not have any such general mechanism for SES nor is one anticipated anytime soon. Thus, for SES, confinement by reloading (i.e., reevaluating) the same sources is currently the only choice. With the coming of first class module loaders http://whatwg.github.io/loader/ this pattern becomes more convenient, but the fundamentals do not change. At some point I'd like to introduce a way for a module to allege that it has no top level state and for the allegation to be checked, i.e., like DeepFrozen or Immutable as applied to modules. For such modules, the same module instance could be shared among subgraphs that should not be able to communicate. But don't hold your breath ;). > > so say if I wanted a Diary object which contains alice/bob/carols > secrets, and ensures the separation of those secrets, you need to > evaluate this source multiple times? > Depends who "I" and "you" are. In the standard scenario Alice sets up the situation by loading/evaluating Bob and Carol. Alice trusts herself, so even without auditors, Alice might trust that this counter code is defensive and provides no more communications opportunity than she intends. Since Bob and Carol are loaded by Alice, they are necessarily fully vulnerable to Alice. If nothing else, Alice could rewrite their code before evaluating "them". So it is not very meaningful for them to be suspicious of Alice. However, Alice can be suspicious of them and they can be suspicious of each other. -- Cheers, --MarkM --089e011609501588f8052e93061b 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 S= un, Mar 20, 2016 at 12:16 AM, Matt Rice <span dir=3D"ltr"><<a href=3D"ma= ilto:[email protected]" target=3D"_blank">[email protected]</a>></span> = wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b= order-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:s= olid;padding-left:1ex">Not really familiar with javascript, but to slightly= modify one of<br> your examples from one of your talks<br> <br> "use strict";<br> <br> var count =3D 0;<br> <br> function makeCounter() {<br> =C2=A0 =C2=A0 =C2=A0// Moved var count =3D 0 from here to above<br> =C2=A0 =C2=A0 =C2=A0// appears to be valid strict javascript afaict<br> =C2=A0 =C2=A0 =C2=A0return def({<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0incr: function() { return ++count;},<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0decr: function () { return --count;}<br> =C2=A0 =C2=A0 =C2=A0});<br> }<br> with the comment in the bottom of the slide:<br> "A tamper-proof record of lexical closures encapsulating state is a<br= > defensive object"<br> <br> so this is 'defensive' rather than 'confined',</blockquote>= <div><br></div><div>Hi Matt, thanks for reminding me of that! As a result, = I have added a short summary section at the beginning of=C2=A0<a href=3D"ht= tps://github.com/FUDCo/ses-realm">https://github.com/FUDCo/ses-realm</a> , = using that example to explain the difference between the "offensive co= de problem" (which confinement addresses) and the "defensive code= problem" which this document had not adequately explained. Please hav= e a look.</div><div><br></div><div><br></div><div>=C2=A0</div><blockquote c= lass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1p= x;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1= ex"> confinement then<br> happens through multiple evaluations of the source code (rather than<br> the evaluator causing error due to the evaluation of the function<br> makeCounter being called in a context where the 'count' variable do= es<br> not exist, did I get that correct?<br></blockquote><div><br></div><div>Yes,= that is correct as stated, but see the answer to your next question. In ge= neral, confinement issues need to leverage what my thesis calls "open = loaders" which obey "loader isolation", as that is how you c= an safely load new code from potential adversaries into an already running = system. The "confine" function I propose, as well as the "ev= al" function and "Function" constructor of the proto-SES rea= lm, are such safe loaders. Since this document is JavaScript centric, I'= ;m using the term "evaluator" for all of these rather than "= loader".</div><div><br></div><div>E and Joe-E are ocap languages with = additional mechanisms to test that an untrusted already-loaded allegedly tr= ansitively immutable object actually is (by the DeepFrozen and Immutable au= ditors, respectively). Given these mechanisms, you can also be sure that ob= jects make by those transitively immutable objects are isolated from each o= ther. However, we do not have any such general mechanism for SES nor is one= anticipated anytime soon. Thus, for SES, confinement by reloading (i.e., r= eevaluating) the same sources is currently the only choice.</div><div><br><= /div><div>With the coming of first class module loaders=C2=A0<a href=3D"htt= p://whatwg.github.io/loader/">http://whatwg.github.io/loader/</a> this patt= ern becomes more convenient, but the fundamentals do not change. At some po= int I'd like to introduce a way for a module to allege that it has no t= op level state and for the allegation to be checked, i.e., like DeepFrozen = or Immutable as applied to modules. For such modules, the same module insta= nce could be shared among subgraphs that should not be able to communicate.= But don't hold your breath ;).</div><div><br></div><div>=C2=A0</div><b= lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le= ft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pad= ding-left:1ex"> <br> so say if I wanted a Diary object which contains alice/bob/carols<br> secrets, and ensures the separation of those secrets, you need to<br> evaluate this source multiple times?<br></blockquote><div><br></div><div>De= pends who "I" and "you" are. In the standard scenario A= lice sets up the situation by loading/evaluating Bob and Carol. Alice trust= s herself, so even without auditors, Alice might trust that this counter co= de is defensive and provides no more communications opportunity than she in= tends. Since Bob and Carol are loaded by Alice, they are necessarily fully = vulnerable to Alice. If nothing else, Alice could rewrite their code before= evaluating "them". So it is not very meaningful for them to be s= uspicious of Alice. However, Alice can be suspicious of them and they can b= e suspicious of each other.</div><div><br></div><div><br></div><div><br></d= iv></div>-- <br><div>=C2=A0 =C2=A0 Cheers,<br>=C2=A0 =C2=A0 --MarkM</div> </div></div> --089e011609501588f8052e93061b-- --===============5870677763833814625== 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 --===============5870677763833814625==--