[Ironpython-users] Restrict referencing of assemblies in hosted environment

Keith Rome rome at Wintellect.com
Wed Oct 17 17:00:45 CEST 2012


Take a look at the PlatformAdaptationLayer class. You can create your own and plug it in to the runtime. This might provide the hooks you are looking for.

In particular, you should be able to override the LoadAssembly() and LoadAssemblyFromPath() methods to block anything that isn't whitelisted for your host environment.


Keith Rome
Senior Consultant and Architect
MCPD-EAD, MCSD, MCDBA, MCTS-WPF, MCTS-TFS, MCTS-WSS
Wintellect | 770.617.4016 | krome at wintellect.com<mailto:rome at wintellect.com>
www.wintellect.com<http://www.wintellect.com/>

From: Ironpython-users [mailto:ironpython-users-bounces+rome=wintellect.com at python.org] On Behalf Of Markus Schaber
Sent: Wednesday, October 17, 2012 6:09 AM
To: Discussion of IronPython
Subject: [Ironpython-users] Restrict referencing of assemblies in hosted environment

Hello,

We're using IronPython as a hosted script engine in our application.

Now, we want to restrict the assemblies a user can reference from its python script,

Currently, we just forbid "import clr", by wrapping the import() method, but this is a bit harsh, and the side-effects are a little bit to strong (e. G. it causes "import minidom.py" to fail...)

However, there seems to be no event or other hook available for AddReference which I could use. It may be possible to add an AssemblyLoading event to the ScriptDomainManager in Microsoft.Scripting.Runtime, which allows to cancel the assembly loading by throwing an exception. Would such a patch be accepted upstream?

An alternative (not-so-elegant) idea is that I just wrap all the AddReference() & Co calls inside the clr module, but there may be a more elegant way.

Isolating Ironpython in its own AppDomain is not an option, as this would require major rework of our Scripting API implementation, and also break backwards compatibility for 3rd party plugins which contribute API for the scripts.

(We don't need a 100% waterproof method -  we know that the user can use cTypes, System.Reflection, or whatever to circumvent everything - we just want to restrict the obvious ways to access some APIs we consider to be internal.)

Best regards

Markus Schaber
--
___________________________
We software Automation.

3S-Smart Software Solutions GmbH
Markus Schaber | Developer
Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 | Fax +49-831-54031-50

Email: m.schaber at 3s-software.com<mailto:m.schaber at 3s-software.com> | Web: http://www.3s-software.com <http://www.3s-software.com/>
CoDeSys internet forum: http://forum.3s-software.com<http://forum-en.3s-software.com/>
Download CoDeSys sample projects: http://www.3s-software.com/index.shtml?sample_projects

Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20121017/d593b50f/attachment.html>


More information about the Ironpython-users mailing list