[IronPython] Sandboxing using AppDomains
Leo Carbajal
desleo at gmail.com
Fri Aug 1 05:29:02 PDT 2008
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 <Colin.Han at grapecity.com>
> 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:* 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:
>
> //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
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ironpython.com/pipermail/users-ironpython.com/attachments/20080801/0345d7fd/attachment-0001.htm>
More information about the Users
mailing list