Hi, 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? -- Zed A. Shaw http://zedshaw.com/
right, i havent been toying with chuck all that long so i'm a newbie, really more of a meganewbie i think, though isn't one of those os features the ability to read files such as .ck files? if you neuter chuck like that, how will it get its code to play? On 1/4/2011 1:26 PM, Zed A. Shaw wrote:
Hi,
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?
On Tue, Jan 04, 2011 at 01:58:55PM -0500, Alan Yoder wrote:
right, i havent been toying with chuck all that long so i'm a newbie, really more of a meganewbie i think, though isn't one of those os features the ability to read files such as .ck files? if you neuter chuck like that, how will it get its code to play?
Well, I'm more talking about the ability of a .ck file to read/write files and access the OS. The actual interpreter should have no problem loading and running files, as it'd have the same access it does now. The difference would be disabling access to that inside the .ck code. -- Zed A. Shaw http://zedshaw.com/
If you run ChucK on a Unix-like system, like Linux or OSX, as a restricted
user, it shouldn't be able to do anything nasty to the actual installation
of the operating system. OTOH, the low-level connection to the sound
interface means that the watchdog needs to be active, or folks can crash
your computer with an endless loop without waits. I'm not completely sure
about the status of the watchdog on Linux.
/Stefan
On Tue, Jan 4, 2011 at 7:58 PM, Alan Yoder
right, i havent been toying with chuck all that long so i'm a newbie, really more of a meganewbie i think, though isn't one of those os features the ability to read files such as .ck files? if you neuter chuck like that, how will it get its code to play?
On 1/4/2011 1:26 PM, Zed A. Shaw wrote:
Hi,
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?
_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
-- Release me, insect, or I will destroy the Cosmos!
On Tue, Jan 04, 2011 at 08:11:25PM +0100, Stefan Blixt wrote:
If you run ChucK on a Unix-like system, like Linux or OSX, as a restricted user, it shouldn't be able to do anything nasty to the actual installation of the operating system. OTOH, the low-level connection to the sound interface means that the watchdog needs to be active, or folks can crash your computer with an endless loop without waits. I'm not completely sure about the status of the watchdog on Linux.
This would be hosted on a virtual linux server somewhere so there isn't a sound dev. Probably what would happen is the scripts would be ran for a short period of time to produce an mp3 and then that gets posted. -- Zed A. Shaw http://zedshaw.com/
thought comes to mind. if the scripts run for a period of time to produce the mp3, and you want a sound outside of that time range. your scripts will say no. i just woke up from a nap, so am probably not being clear. if you've got a 20 second piece, and your scripts say run for 10 seconds, those last 10 seconds are going to go away never to be heard. On 1/4/2011 6:49 PM, Zed A. Shaw wrote:
On Tue, Jan 04, 2011 at 08:11:25PM +0100, Stefan Blixt wrote:
If you run ChucK on a Unix-like system, like Linux or OSX, as a restricted user, it shouldn't be able to do anything nasty to the actual installation of the operating system. OTOH, the low-level connection to the sound interface means that the watchdog needs to be active, or folks can crash your computer with an endless loop without waits. I'm not completely sure about the status of the watchdog on Linux. This would be hosted on a virtual linux server somewhere so there isn't a sound dev. Probably what would happen is the scripts would be ran for a short period of time to produce an mp3 and then that gets posted.
On Tue, Jan 04, 2011 at 07:56:33PM -0500, Alan Yoder wrote:
thought comes to mind. if the scripts run for a period of time to produce the mp3, and you want a sound outside of that time range. your scripts will say no. i just woke up from a nap, so am probably not being clear. if you've got a 20 second piece, and your scripts say run for 10 seconds, those last 10 seconds are going to go away never to be heard.
Yeah, and playing around with this it'll require a bit of engineering to allow saving to mp3 files but not anything else. Well I think I'll have to come up with a different approach then. -- Zed A. Shaw http://zedshaw.com/
On Tue, Jan 4, 2011 at 8:28 PM, Zed A. Shaw
On Tue, Jan 04, 2011 at 07:56:33PM -0500, Alan Yoder wrote:
thought comes to mind. if the scripts run for a period of time to produce the mp3, and you want a sound outside of that time range. your scripts will say no. i just woke up from a nap, so am probably not being clear. if you've got a 20 second piece, and your scripts say run for 10 seconds, those last 10 seconds are going to go away never to be heard.
Yeah, and playing around with this it'll require a bit of engineering to allow saving to mp3 files but not anything else. Well I think I'll have to come up with a different approach then.
I think the trick would be to have an always-running shred in the background, like: while (1) { 1::day => now; } Then you could continously stream the output, and people could spork other stuf on the same VM and it would get mixed in. Probably it wouldn't be that hard to compile a version of ChucK without any access to the file system. It might be nice to have some level of process control. Like, list the running shreds and be able to kill them... just in case someone leaves something running and logs out. (Oh! It might be nice to actually track which user spawned which shred and kill them when he logs out.. that would take more work though.) I've thought of this idea myself, I think it would be fun to have a server running and be able to improvise with other people. One problem is that if someone does something stupid like while(1){};, then it will block everyone else's fun. Some kind of processing cap per shred should be imposed. Steve
On Tue, Jan 4, 2011 at 10:26 AM, Zed A. Shaw
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/
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.
participants (6)
-
Alan Yoder -
Kassen -
Stefan Blixt -
Stephen Sinclair -
Tom Lieber -
Zed A. Shaw