[chuck-users] chuck in a safe box?

Kassen signal.automatique at gmail.com
Thu Jan 6 16:41:37 EST 2011


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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cs.princeton.edu/pipermail/chuck-users/attachments/20110106/bd054f3d/attachment.html>

More information about the chuck-users mailing list