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.

We did disable Std.system( string ) by default. That's the biggest thing.

File I/O will be a issue but on Unix chuck could be granted access only to a small directory or no read/write access at all.

That last option should also solve the potential questions about writing wave files to disk in a way that might clog the file system.

There may be more.

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.

Hmmmm.... but how would you then add more code?

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.

Watchdog works, but it's chiefly useful when ChucK is a part of the mini as the terminal version can't spawn a popup window, I'm not sure whether watchdog can currently call to outside processes, if not that might be a good idea. If so it should be documented.

Yours,

Kas.