Re: ControlThread (SecurityPermission)

From: Dave (kdlevine@wi.rr.com)
Date: 03/24/03

  • Next message: Jack: "Late-binding, pointers and callback" 
    From: "Dave" <kdlevine@wi.rr.com>
Date: Mon, 24 Mar 2003 00:12:45 -0600

    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?

  • Next message: Jack: "Late-binding, pointers and callback"

    Relevant Pages

    • 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: ControlThread (SecurityPermission)
      ... I did consider loading the plugin into a seperate ... ability to force that AppDomain to unload. ... >> I find however that even without the ControlThread ...
      (microsoft.public.dotnet.security)
    • 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)
    • Re: Creating a Singleton that is a cross AppDomain Singleton
      ... public abstract class Plugin: MarshalByRefObject ... This would ensure that every plugin must be a MarshalByRefObject so you ... invoke methods on them without having them get loaded in that AppDomain. ... >> for the plugin assemblies only to be loaded in the second AppDomain you ...
      (microsoft.public.dotnet.csharp.general)