[IronPython] Scripting use with security pointers wanted

J. Merrill jvm_cop at spamcop.net
Mon Oct 24 17:13:55 CEST 2005


.Net has a notion called "code access security" that allows you to control what your code is able to do when called by someone else (and many other things).  If you Google for "code access security" ".net" --

http://www.google.com/search?hl=en&lr=&q=%22code+access+security%22+%22.net%22

you'll see many pointers to discussions, documentation, and code samples.

It should not be necessary to use another AppDomain to get the security you want.  The only real advantage of using another AppDomain is that malicious code can cause a "denial of service" problem by misbehaving if it runs in the same AppDomain as your app; if the code is running in its own AppDomain, it won't affect things permanently because you can deal with it being non-responsive by shooting the other AppDomain.

However, there are some restrictions on what can be done across AppDomains (related to the requirement that data be "marshalled" across the AppDomain boundary), and everything is (somewhat) slower than would be the case if everything's within the same AppDomain.

Good luck...

At 02:01 AM 10/23/2005, Michael Latta wrote
>I would like to use IronPython for scripting, but that poses large security
>concerns.
>Any pointers would be welcome.
>
>1) How to run the scripting code in a secure manner, but give it access to
>the public API needed to script the application.
>2) How do I run IronPython code in a separate AppDomain?
>3) How do I give that other app domain restricted access to my API?
>4) How do I set it up so the app domain is running with low security
>privileges?
>
>Most of this is not specific to IronPython, but hopefully someone here has
>done this already.  It would be great if there were a standard module/method
>for doing this out of the box.  I could see having a generic class
>IronPythonScript<API> that takes an API type and results in an object that
>manages the other app domain, and exposes an interface for loading and
>executing scripts, while providing an object of the API type to the scripts
>as a point of interface with the application.
>
>Michael


J. Merrill / Analytical Software Corp




More information about the Ironpython-users mailing list