Sig, If I am following, then the command line flag you describe is the only way to be certain anyway. Otherwise, one could fall victim to an FFI library that happens to be visible to the vm, and one's head is in the sandbox at that point - fair??
Of course, there are evils, and then there are evils. Things like openssl are unlikely to go wrong in my experience, and they offer functionality that is hard to replace, and stature that might be impossible to replace (we want _that_ library...). Besides, if you don't want things crashing, what are you doing on Windows? :) Bill -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Igor Stasenko Sent: Tuesday, February 24, 2009 7:02 PM To: [email protected] Subject: Re: [Pharo-project] Towards Pharo 1.0 What about more generic security rule: - allow/deny to use external modules ? then VM could simply check this flag at attempt of loading ANY external module - be it plugin or something else. Then, it is safe to ship VM with FFI built-in, and you can even run FFI tests, because test functions will be sitting inside a VM but not in an external library. But once you try to make a call which requires loading new dynamic library - you will have a primitive failure. As you maybe know, in windows, when you loading a .dll, OS calling a DllMain function. And there are a chance that it can do something evil, what may crash VM and your sandbox is no longer a sandbox :) -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
