[IronPython] Sandboxing using AppDomains

Han Kejing Colin.Han at grapecity.com
Thu Jul 31 08:14:13 CEST 2008

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: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] 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.



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: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Leo Carbajal
Sent: 2008年7月31日 10:07
To: Users at lists.ironpython.com
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:

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");           
            engine.ExecuteFile(script, engine.DefaultModule, locals);

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.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20080731/3354f595/attachment.html>

More information about the Ironpython-users mailing list