[chuck-users] chuck in a safe box?

[Tom Lieber]

On Tue, Jan 4, 2011 at 10:26 AM, Zed A. Shaw <zedshaw at zedshaw.com> wrote:
> I'm toying with a small idea to let people upload bits of chuck code to
> a website and then have it play out to the world.  I haven't started
> coding anything yet, but I was wondering how hard it is to put ChucK
> into a safe environment so that it can't touch the OS?  In Lua I'd do
> that by ripping out the various OS features.  Is there a similar thing
> with Chuck?

My roommate did this project a few years ago (actually, it was
collaborative ChucKing), but I don't know if he handled the security
issues. I'll ask. However, since that time more unsafe APIs have been
added, so even if they did, their patch might not be too useful.

I think it would take some work to find all the places where ChucK
performs operations you wouldn't want to do in a sandbox. There's no
--sandbox option, though the undocumented --standalone gets you
started. It turns off network listening for on-the-fly VM commands.
AFAIK it's only referenced in the VERSIONS file and chuck_main.cpp.

You'd also have to patch the file I/O calls that were added recently,
the various types of network calls like OSC, the ways of saving audio
to disk (as with WvOut), and probably others I'm not thinking of.
Nothing difficult, it's just you might not be able to know when you've
plugged all the holes.

And Stephen's right that you'd definitely need a watchdog outside of
ChucK since a shred can halt virtual time indefinitely with an
infinite loop. If you're spawning a ChucK per job that's simple, but a
long-running ChucK would be complicated. There's --watchdog (another
undocumented flag), but it's not clear how/if that works.

-- 
Tom Lieber
http://AllTom.com/
http://ckvlang.org/