Generally we do advocate creating a separate AppDomain for different trust levels -- trying to ensure that each AppDomain has at most two trust levels, FullTrust and one partial trust set. The reasoning is that any assembly in an AppDomain can access any other assembly loaded into the domain. Which means it is generally trivial for an assembly running at a low trust level to elevate its trust to a higher level by routing its calls via an assembly at a higher trust level. While FullTrust code is often audited for security when being called by partially trusted code, partial trust assemblies are generally not.
That being said, seeing what it would take to get IronPython to run partial trust has been something I've been meaning to investigate for a while now -- its just been on the back burner. The actual Python engine itself will require FullTrust because IronMath.dll contains some unverifiable code. However that should not be a problem, as long as you can coerce the code generated for the Python scripts to run partial trust. That's where the issue lies -- since IronPython is using lightweight code gen, the code generated from the script runs in the same security context as the assembly it was emitted into -- in this case the fully trusted IronPython.dll In addition to partial trust issues, there is the possibility of marshalling issues that were pointed out previously in this thread. I imagine this will be a bit of an uphill battle at first, however a good start would be to recompile IronPython with a strong name, and use the new Simple Sandboxing API (http://blogs.msdn.com/shawnfa/archive/2005/08/08/449050.aspx) to create a partial trust sandbox that granted FullTrust to IronMath, and partial trust to IronPython to work around the above issue. Then some trial and error will be needed to see how well the Python engine works in partial trust. -Shawn http://blogs.msdn.com/shawnfa -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of J. Merrill Sent: Monday, October 24, 2005 8:14 AM To: Discussion of IronPython Subject: Re: [IronPython] Scripting use with security pointers wanted .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 _______________________________________________ users mailing list [email protected] http://lists.ironpython.com/listinfo.cgi/users-ironpython.com _______________________________________________ users mailing list [email protected] http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
