Sandboxing Io

Hello all.

I looked into Io awhile back, then fell out of projects that needed
scripting and fell away. I've just come back out of curiosity, and am
liking what I'm seeing.

I do have one concern, though, because some of the places I would want
to allow scripting would be from "untrusted" sources -- game AI
scripts, program editor utility scripts, etc -- and I'd like to be
able to "sandbox" Io. In particular, I would like to ensure that a
script has no way to access any part of the host computer without
coming through a CFunction that I wrote and registered in my scripting
host program.

I did a quick search on the mailing list, and the messages about
sandboxing appeared to be about sandboxing one Io instance from
another (which is very cool, but not what I'm trying to protect).

It appears that the File primitive (and possibly others) breaks this
sandboxing ability, and that the File primitive is actually part of
the Core, rather than an addon. Is this the case, or are there levels
of "addon-ness"; to the Core? I see that there are separate files for
IoFile and IoFile_stat -- can I simply not include those in a build
and still have a functional Io interpreter?

As before, I carry certain prejudices around with me from my Lua
experience, and the complete sandboxing possibly with Lua's core
appealed to me (Lua's core is of dubious standalone use, as it cannot
touch anything outside the interpreter at all -- it requires
registered CFunctions to provide any form of input, output, or access
-- but that is exactly what I want from my embedded interpreter). I
like having standard classes/libraries/addons for common things when I
want to use Io for my own programming, but if I accept a utility
script from a user I want to know that they can't hurt my machine.

Thanks for any info,
Mac

--
"But it's much better to face these sorts of things with a sense of
poise and rationality" (and if you can't swing that, try poisoned
rationality...)

Hi Mac,

Sandboxing can partially be achieved by starting another Io vm and
removing all references to unsafe objects. Without references to the
unsafe objects, it won't be possible for the code to access the
dangerous CFunctions.

If you were embedding Io within your application, you could even go to
the extent of creating a custom IoState initialization function for
creating the sandboxed vm.

However, using another Io vm doesn't protect you from:
1. memory usage
2. cpu usage
3. crashing the vm

All of which are easy to do.

A while back, I had hooks deep into the vm so cpu time could be
limited. Similar patches could be added in.

Steve's new memory tracking code might be able to be extended to also
limit memory usage.

Fixing the segfaults and other crashes in Io will take time.

If you are interested in working on sandboxing, you'll find popular support.

Thanks,
Jonathan.

On 3/6/07, Mac Reiter < reiter%40nomadics.com">reiternomadics.com> wrote:
&gt; Hello all.
>;
> I looked into Io awhile back, then fell out of projects that needed
&gt; scripting and fell away. I've just come back out of curiosity, and am
> liking what I'm seeing.
>
> I do have one concern, though, because some of the places I would want
>; to allow scripting would be from "untrusted" sources -- game AI
> scripts, program editor utility scripts, etc -- and I'd like to be
> able to "sandbox" Io. In particular, I would like to ensure that a
> script has no way to access any part of the host computer without
> coming through a CFunction that I wrote and registered in my scripting
> host program.
>
>; I did a quick search on the mailing list, and the messages about
&gt; sandboxing appeared to be about sandboxing one Io instance from
>; another (which is very cool, but not what I'm trying to protect).
>
&gt; It appears that the File primitive (and possibly others) breaks this
>; sandboxing ability, and that the File primitive is actually part of
> the Core, rather than an addon. Is this the case, or are there levels
&gt; of "addon-ness"; to the Core? I see that there are separate files for
> IoFile and IoFile_stat -- can I simply not include those in a build
&gt; and still have a functional Io interpreter?
>
> As before, I carry certain prejudices around with me from my Lua
> experience, and the complete sandboxing possibly with Lua's core
>; appealed to me (Lua's core is of dubious standalone use, as it cannot
&gt; touch anything outside the interpreter at all -- it requires
> registered CFunctions to provide any form of input, output, or access
&gt; -- but that is exactly what I want from my embedded interpreter). I
> like having standard classes/libraries/addons for common things when I
> want to use Io for my own programming, but if I accept a utility
> script from a user I want to know that they can't hurt my machine.
>
>; Thanks for any info,
&gt; Mac
>
> --
> "But it's much better to face these sorts of things with a sense of
> poise and rationality" (and if you can't swing that, try poisoned
> rationality...)
&gt;
>
>
>;
>
> Yahoo! Groups Links
&gt;
>
>
>;