[IronPython] Sandboxing using AppDomains

[Leo Carbajal]

I will have to try it out, then. At the very worst I can always set up the
shell and then apply the proper permissions (or lack thereof) later when its
supported, I doubt my own project will be going live any time soon anyway so
a little leeway in testing is no big deal.

Now to wrap my head around the new hosting API, maybe a third read through
on the docs will help. =\


2008/8/1 Dino Viehland <dinov at exchange.microsoft.com>

>  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 L
> .
>
>
>
> *From:* users-bounces at lists.ironpython.com [mailto:
> users-bounces at lists.ironpython.com] *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 <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
>
>
>
> _______________________________________________
> 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://mail.python.org/pipermail/ironpython-users/attachments/20080801/031c044a/attachment.html>