Before reading your post I thought that there was a security problem only if a NetLogo program had a network extension but your scenario is possible.
Historically this concern about security wasn't large because anyone worried could use the Java applet version of a model and stay safely in the applet sandbox. In theory that should have worked but Sun/Oracle blew it. Soon that kind of option will return via Tortoise -- no security concerns about running the JavaScript equivalent of a NetLogo model. Regarding security and extensions it depends (just as it did with Java applets where some extensions were allowed). Presumably the safe extensions (e.g. matrices) could be supported by Tortoise unlike a file extension. (Though after writing this it occurred to me that file-like operations could be implemented in Tortoise by storing the contents of the files in the browser's local storage (typically capped at 50MB). I frequently hear teachers complain that their school computers are so locked down (for security reasons) that they have great difficulty getting anything installed. Tortoise seems the only answer. (A student wanting to hack their school's computer could use auto-loading NetLogo extensions if NetLogo was installed.) Best, -ken On 20 March 2015 at 22:14, Forrest Stonedahl <[email protected]> wrote: > Ken Kahn wrote: > > >> Since extensions can do anything that Java can the automatic loading of >> extensions should probably be limited to CCL maintained extensions. No >> point enabling NetLogo malware. >> > > An interesting point, which I hadn't considered. However, NetLogo > programs themselves are fairly powerful, with file I/O access, and the > special "startup" procedure allows code to be run when the model loads... > so it would still be possible for a rogue NetLogo model to do something > nasty, just by opening it. > > For instance, the model *might* be able to use the file-write command to > overwrite certain executables on your system with custom code, and you > might not know until the next time you run that program. Furthermore, it > *might* be possible to make a NetLogo model that does this, and then > re-writes its own source code with a cleaned up version (sans startup > routine), and reloads itself, to hide the fact that something nefarious > happened. > > I haven't tried these techniques, so there might be some barriers that I'm > not aware of.... some of it is made more difficult by the lack of good file > system manipulations in NetLogo (e.g., searching for good executable files > to overwrite, etc) but I guess my point is: NetLogo was never designed with > a security model in mind that would prevent models from doing *bad > things*. It's true that it would be a WHOLE LOT easier to write powerful > malware in a Java extension... but a devious person can probably to do so > in NetLogo language itself. > > Of course, writing an ABM in another language (Java, Python, etc), no one > *expects* to have a constrained security model... perhaps NetLogo's > friendly appearance belies its power as a programming language. I guess the > best advice, from a security perspective, is this: only run programs > (including NetLogo models) from people that you trust (or verify the source > code first, by opening it in an external text editor). > > That said, I don't imagine NetLogo will ever be a big target for malware > authors. It's simply too niche. > > Cheers, > > ~Forrest > > -- You received this message because you are subscribed to the Google Groups "netlogo-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
