One thing I’ll point out is in 2.0 we’ve done a bunch of work to make working with a remote app domain pretty easy. You can create the ScriptRuntime in the remote domain and get back a ScriptEngine which lives in the remote domain. All of the calls on the hosting APIs use serializable / MBRO objects so that they’re safe to use from a remoting standpoint. Also ObjectOperations provides versions of the APIs that work with ObjectHandle’s instead of raw objects. So all you have to watch out for is making sure the objects you’re sending across the wire are MBRO or Serializable.
That being said we still have a few bugs which prevent you from creating a completely untrusted domain and loading the ScriptRuntime over there. Those should be getting resolved fairly soon though but won’t be in 2.0 Beta 4 :(. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Leo Carbajal Sent: Friday, August 01, 2008 5:29 AM To: Discussion of IronPython Subject: Re: [IronPython] Sandboxing using AppDomains I had seen that series, though I admit I missed the posts on not using deny. Still rather leaves me in a bind, I guess I'll just have to see how passing object references works through an AppDomain. --- LC 2008/7/31 Han Kejing <[EMAIL PROTECTED]<mailto:[EMAIL PROTECTED]>> Hi, Leo, Maybe follows document is helpful for you. http://blogs.msdn.com/shawnfa/archive/2005/08/08/449050.aspx PermissionSet.Deny is not safe. User code may use PermissionSet.Assert to get the power easily. ---------------------------------------------------------------- Follow my heart Colin Han @ MultiRow Developer Team (A Strong Team) From: [EMAIL PROTECTED]<mailto:[EMAIL PROTECTED]> [mailto:[EMAIL PROTECTED]<mailto:[EMAIL PROTECTED]>] On Behalf Of Leo Carbajal Sent: 2008年7月31日 10:07 To: [email protected]<mailto:[email protected]> Subject: [IronPython] Sandboxing using AppDomains Howdy all, I know this is a topic that comes up again and again but I was hoping I could get a bit of understanding from someone. So, like many others, I'm looking to get IPy to work in a relatively safe environment. My application is a game-server and exposes many entry points for user created scripts to essentially extend the game's reactions. Because these scripts are open to the public I need to be sure that it cannot do nasty things like delete all the script files, my app or anything else on the server, access my other non-exposed functions, etc. Anyway, so after reading up a little on AppDomains it sounds like running IPy through one could be a little prohibitive. I'm not really passing value-types to work on, I'm allowing the scripts to directly access and modify the objects themselves. I guess I'm not sure if what I want to do will even work, and I haven't had a chance to put together a test. The use of scripting in the application is extensive so I worry that I may have to scale back - or risk having someone one day using a little reflection to snoop out my app's API and calling functions that the scriptShell was never intended to be able to use. Would using permission.Deny for the permissions I want to disallow be enough to keep things safe? I.E. something like: //elsewhere private static PermissionSet ps = new PermissionSet(PermissionState.None); ps.AddPermission(new SecurityPermission(SecurityPermissionFlag.Execution)); ps.AddPermission(new FileIOPermission(FileIOPermissionAccess.PathDiscovery | FileIOPermissionAccess.Read, Path)); public static void PlayFirstFile(Item caller) { locals.Add("Artifact", new ScriptableItem(caller)); string script = (Path + "script.py"); ps.Deny(); engine.ExecuteFile(script, engine.DefaultModule, locals); locals.Clear(); } ScriptableItem, by the way, is a class wrapper to hide private methods in Item after I found out that passing something as a template doesn't work to occlude methods\properties I don't want called. =\ I'm a little lost when it comes to all this security stuff, I could really use a bit of explanation and would really appreciate any help that can come this way. I'm using IronPython 1.1.2 as I haven't had the chance to sit down and really play with 2.0, it seems a bit more convoluted to set-up but thats entirely a from-the-outside perspective at the moment. --- LC _______________________________________________ Users mailing list [email protected]<mailto:[email protected]> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
_______________________________________________ Users mailing list [email protected] http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
