Sorry, My English is so bad. I cannot write more details about this topic. I had a sample to test the security of .NET FW. If you want it, you can send mail to me (colin DOT han AT grapecity DOT com). I will send it to you.
---------------------------------------------------------------- Follow my heart Colin Han @ MultiRow Developer Team (A Strong Team) From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Han Kejing Sent: 2008年7月31日 14:04 To: Discussion of IronPython Subject: Re: [IronPython] Sandboxing using AppDomains 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] On Behalf Of Leo Carbajal Sent: 2008年7月31日 10:07 To: [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] http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
