Re: Fwd: Fwd: Draft Proposed Standard SES (Secure EcmaScript)

--===============5213918846850782436==
Content-Type: multipart/alternative; boundary=001a11405936073e76052e866f2f

--001a11405936073e76052e866f2f
Content-Type: text/plain; charset=UTF-8

On Sun, Mar 20, 2016 at 6:02 PM, Matt Rice <[email protected]> wrote:

>  the point i was trying to make is when
> makeCounter is untrusted code, and we can eval untrusted code into a
> confined space, and makeCounter can do such a thing, we can load
> confined code, but passing objects created by the untrusted code to
> multiple parties seems delicate.


The point I now realize I was trying to make yesterday is that without a
way to turn off language primitives, it isn't safe to offer a remote eval.
I've got this pet project which is a security infrastructure that allows
safe remote procedure calls via such a mechanism, so instead of having to
write parsing libraries, the language's own text-eval feature is used, only
the context it is used in doesn't know any verbs aside from the ones in the
published api.

Given a counter object with (incr,decr,read) as its full API, one would
invoke it by sending it an incr-token, a decr-token, or a read-token and
getting the resulting value back as an integer message.

With access to the full-API channel, you could delegate part of that via a
proxy.

Mark Miller's proposed securer subset of Javascript isn't envisioned to go
that far. Not about making subdelegations, but by allowing sub-delegations
via a limited text-eval feature that syntactically is the same as the
language's normal text-eval feature: providing untrusted access from
outside the language instance to a counter object will still require some
message parsing, { eval (the untrusted message) } won't do it, even with
pass-by-language-global disallowed. A restricted eval would be required for
safe JSONP message passing; the new MIME-type suggested at
http://json-p.org/ is exactly such a restricted eval, that is, it is a
parser that only understands scripts containing exactly one function call
with nothing but literal data as arguments.

--001a11405936073e76052e866f2f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Sun, Mar 20, 2016 at 6:02 PM, Matt Rice <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:[email protected]" target=3D"_blank">[email protected]</a>&gt;<=
/span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-l=
eft-style:solid;padding-left:1ex">=C2=A0the point i was trying to make is w=
hen<br>
makeCounter is untrusted code, and we can eval untrusted code into a<br>
confined space, and makeCounter can do such a thing, we can load<br>
confined code, but passing objects created by the untrusted code to<br>
multiple parties seems delicate.</blockquote><div><br></div><div>The point =
I now realize I was trying to make yesterday is that without a way to turn =
off language primitives, it isn&#39;t safe to offer a remote eval. I&#39;ve=
 got this pet project which is a security infrastructure that allows safe r=
emote procedure calls via such a mechanism, so instead of having to write p=
arsing libraries, the language&#39;s own text-eval feature is used, only th=
e context it is used in doesn&#39;t know any verbs aside from the ones in t=
he published api.</div><div><br></div><div>Given a counter object with (inc=
r,decr,read) as its full API, one would invoke it by sending it an incr-tok=
en, a decr-token, or a read-token and getting the resulting value back as a=
n integer message.</div><div><br></div><div>With access to the full-API cha=
nnel, you could delegate part of that via a proxy.</div><div><br></div><div=
>Mark Miller&#39;s proposed securer subset of Javascript isn&#39;t envision=
ed to go that far. Not about making subdelegations, but by allowing sub-del=
egations via a limited text-eval feature that syntactically is the same as =
the language&#39;s normal text-eval feature: providing untrusted access fro=
m outside the language instance to a counter object will still require some=
 message parsing, { eval (the untrusted message) } won&#39;t do it, even wi=
th pass-by-language-global disallowed. A restricted eval would be required =
for safe JSONP message passing; the new MIME-type suggested at=C2=A0<a href=
=3D"http://json-p.org/">http://json-p.org/</a> is exactly such a restricted=
 eval, that is, it is a parser that only understands scripts containing exa=
ctly one function call with nothing but literal data as arguments.</div><di=
v><br></div><div><br></div></div>
</div></div>

--001a11405936073e76052e866f2f--

--===============5213918846850782436==
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

--===============5213918846850782436==--