[IronPython] Scripting use with security pointers wanted

Michael Latta lattam at mac.com
Mon Oct 24 21:22:41 CEST 2005

Thanks for the pointers.  I want to make sure my scriptable app is not
creating security holes like ActiveX created in the past with full trust
loaded content.  At the same time there are aspects I would like to
implement that require good performance.  Using a general purpose language
for app extension may be part of the issue.  What I want is a language that
can be used to add custom behavior to the app, but I want to restrict what
that behavior can do to the public API my app exposes.  At the same time,
letting add-ons do advanced things can make the infrastructure much more
adaptable and usable in the market.  It is not practical to marshal the app
data to another app domain, it might be reasonable to marshal action objects
from the extension app domain to the application.  This ensures that only
approved actions execute in the application domain.  But, then only those
actions can affect the application.  Either the actions need to be very
basic and general (property access, etc), or the custom logic needs to
execute in the application domain.  I guess it really comes down to how much
overhead is there for each API call to marshal an action object between app

I think this is going to require some experimentation to resolve.


-----Original Message-----
From: users-bounces at lists.ironpython.com
[mailto:users-bounces at lists.ironpython.com] On Behalf Of Shawn Farkas
Sent: Monday, October 24, 2005 11:49 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Scripting use with security pointers wanted

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

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


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


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
>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
>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
>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.

J. Merrill / Analytical Software Corp

users mailing list
users at lists.ironpython.com
users mailing list
users at lists.ironpython.com

More information about the Ironpython-users mailing list