Re: ControlThread (SecurityPermission)

From: Andrew (whatabohr@hotmail.com)
Date: 03/24/03 

From: "Andrew" <whatabohr@hotmail.com>
Date: Mon, 24 Mar 2003 13:05:43 -0800

I did consider loading the plugin into a seperate
AppDomain. You are correct that doing so gives me the
ability to force that AppDomain to unload.

This is actually the solution that I am working on right
now, but I am running across some marshalling problems
with moving data between the two AppDomains. I think
that I can work around most of these problems if I have
to, but I would rather avoid the marshalling problems
unless I have to.

 ~ Andrew

>-----Original Message-----
>Have you tried executing the plugin in a separate
appdomain? When you unload
>the appdomain all threads running within it will be
unwound to the appdomain
>boundary, which will usually mean that all threads
created within that
>appdomain will be terminated.
>
>"Thread enumeration" <whatabohr@hotmail.com> wrote in
message
>news:383801c2f1c6$63231f60$3001280a@phx.gbl...
>> I am writing an application which needs to allow
>> partially trusted plugins to execute. I load these
>> assemblies with very few permissions (In fact, I have
>> tried it with _nothing_ but execute).
>>
>> I find however that even without the ControlThread
>> SecurityPermission being assigned, the plugin code
still
>> seems to have full control over creating a thread and
>> setting priority. I need a way to prevent the plugin
>> (which is potentially malicious) from creating a new
>> thread and performing a DOS against legitimate code.
>>
>> When I call into a plugin I create a thread and execute
>> on that thread (having assigned it a lower priority)
then
>> I have a monitor thread which is capable of aborting
the
>> plugin thread if it doesn't return after a timeout.
This
>> works great, what I cannot do is prevent the plugin
from
>> spawning a thread (which I have no way of controlling)
>> which survives after I kill the parent thread.
>>
>> If there was some way I could enumerate the managed
>> threads, then perhaps I could identify these leftover
>> threads and abort them, but I cannot find a way to do
>> this. From a System.Diagnostics.Process instance I can
>> enumerate the unmanaged threads, but there seems to be
no
>> way to translate from these to managed Thread objects,
>> nor any way to terminate them.
>>
>> Any thoughts?
>
>
>.
>

Relevant Pages

  • Re: Plugins and AppDomain(s) - One or many?
    ... I suppose that if some data was lost when the AppDomain is unloaded it is ... You could put each plugin into a separate appdomain but this ... > common/shared assemblies are dealt with, ... > also means that you must unload all the plugins to unload any of them. ...
    (microsoft.public.dotnet.general)
  • PlugIn dynamisch laden und Berechtigungen festlegen(Sandbox)
    ... Das PlugIn soll mit der ASP.NET Anwendung kommunizieren. ... 'Create a new AppDomain PolicyLevel. ... Dim domainPolicy As PolicyLevel = PolicyLevel.CreateAppDomainLevel ...
    (microsoft.public.de.german.entwickler.dotnet.csharp)
  • Re: Plugins and AppDomain(s) - One or many?
    ... this grouping is that all plugins in the same appdomain will get unloaded at ... You could put each plugin into a separate appdomain but this ... common/shared assemblies are dealt with, ... also means that you must unload all the plugins to unload any of them. ...
    (microsoft.public.dotnet.general)
  • Re: Loading plugins in separate AppDomains
    ... In order for the plugin assemblies only to be loaded in the second AppDomain ... > MarshalByRefObject) in an assembly that implements the IPlugin interface. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Plugin difficulties
    ... if you set the ApplicationBase to the plugin directory ... > and then set the PrivateBinPath to the bin directory, ... Assemblies that are loaded in the secondary AppDomain, ...
    (microsoft.public.dotnet.framework.clr)