Tom; 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.